On 24.01.2018 22:32, Julian Foad wrote: > When 'svn patch' applies an 'add file' patch onto a WC path whose > local schedule is 'delete', it changes the schedule to 'replace'. > > Sequences such as this... > > > svn rm foo > > svn diff > rm-foo.diff > > svn patch --reverse-diff rm-foo.diff > > or this... > > > svn add foo > > svn diff > add-foo.diff > > svn commit > > svn patch --reverse-diff add-foo.diff > > svn patch add-foo.diff > > ... result in 'foo' being scheduled as 'replace'. > > stsp and I discussed on IRC ( > http://colabti.org/irclogger/irclogger_log/svn-dev?date=2017-12-15#l19 > ) and agreed that this is not what users would generally want or expect. > > I propose to make 'patch' always generate a 'modified' (or unmodified) > schedule when it applies an 'add file' diff (or reverse-applies a > 'delete file' diff) onto a schedule 'deleted' working copy file. > > It is not inherently necessary that shelving and manual use of 'svn > patch' should share the same solution, but in this case I think that > is best.
Why is this not what users would expect? "Delete" + "add" has always been "replace" in Subversion. The only other reasonable option I can think of would be to generate a delete/add tree conflict and let the user decide what to do about it. Silently undoing an "svn rm" in the working copy is exactly what I would _not_ expect. Both 'svn rm' and 'svn patch' are explicit user operations and we can't just assume that one or the other were mistakes. -- Brane
