[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN-4709 shelve: deleted file becomes 'replaced'

From: Branko ─îibej <brane_at_apache.org>
Date: Thu, 25 Jan 2018 01:49:19 +0100

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
Received on 2018-01-25 01:49:32 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.