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

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