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

Re: [r25803] Interactively dealing with obstructed-addition conflicts

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2007-07-21 01:52:31 CEST

On 20/07/2007 19.56, Daniel Rall wrote:

> I'm really hesitant to flat-out destroy the modified content in the
> user's WC (choose_repos option), even upon their request. I can see
> why an experienced user might want this behavior, but it's a definite
> gotcha for the newbie who selects the wrong option without a full
> understanding of the repercussions. Moving it aside into an
> unversioned foo.discarded file seems like a safe -- if potentially
> annoying -- behavior (possibly overridable in ~/.subversion/config?).

In my own experience, 99% of the obstructions in merges are just leftovers of
previous uncommitted merges. Eg, the typical combo:

$ svn merge [...]
$ svn revert -R .
$ svn merge [...]

will cause many obstructed files to be present and skipped by default (!) even
if they have the same contents of what we were trying to add.

I think there are two parallel fixes for this:

1) If the obstructing file has the same content of the obstructed file, it is
not a real obstruction. svn should notice this.

2) If I revert after a merge, added files should simply go. There's no point
in keeping them around (unless they've been modified of course). I think the
rule is: if I svn copy a file and then revert it, svn should just remove it
(unless it's modified). Notice that this is different from a file being added
without copy-from (svn add instead of svn cp): in the case of svn add, you
want to keep the unversioned file on the disk.

Giovanni Bajo
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 21 01:51:55 2007

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.