Re: Bad interaction between merge and revert

On Sat, 2004-07-31 at 07:41, Daniel Egger wrote:

> The only way to make this work reliably is to remove the WC and
> start with a completely fresh checkout

Not true! There's a much easier way to re-try the merge.

If you run 'svn merge', you end up with local modifications of three
kinds: edits, adds, deletes.

If you don't like the result, and want to revert all the local changes,
then 'svn revert -R' will do the job, but it WILL NOT make your working
copy look *exactly* as it used to. The reversion will undo the edits;
it will bring back deleted files; but the 'added' files will not be
destroyed. Instead, they're left behind as 'unversioned' files.

So you need to remove the formerly-added, now-unversioned files.
Usually you can run 'svn status' and then delete anything with a '?'
next to it (or write a script to do that.)

If you don't do this, then a repeat of the merge will try to re-add the
files, and abort when an unversioned file of the same name is 'in the
way'.

(The reason for this revert behavior is due to svn's prime directive:
never destroy data. It would be unacceptable for 'touch foo; svn add
foo; svn revert foo' to destroy the file.)

So the proper algorithm is:

  svn merge
  svn revert -R
  delete unversioned files and dirs
  svn merge (again)

I admit, this bites people quite often, and has become a FAQ. I wonder
if it would be nice to add another switch to 'svn revert' that tells it
to destroy any unversioned files.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 31 16:03:12 2004