On Wed, Jan 24, 2018 at 6:49 PM Branko Čibej <brane_at_apache.org> wrote:
> 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.
>
>
FWIW, I agree with Branko. By starting a tree conflict the user can chose
a path to go. If svn marked the file modified, they would not actually
have a way to accomplish a "replace" if that was the desired behavior
(though I suppose a delete, commit, then 'svn patch' could be used in that
scenario).
Troy
-- Brane
>
>
Received on 2018-01-25 03:46:57 CET