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

Re: Bad interaction between merge and revert

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-01 16:29:04 CEST

Ben Collins-Sussman wrote:
>
> 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.

That sounds like a deficiency of revert. A deficiency that, in trivial cases, is unimportant because it is easy to clean up by hand, but in larger scales it can be a real nuisance.

Won't a file added by 'merge' always be added as a copy of an existing versioned file? In that case, removing it would not lose data because the file contents are known to be preserved elsewhere, so 'revert' could safely remove it. That would seem to me to be appropriate behaviour.

(If I'm wrong about this, then perhaps 'merge' needs to store some meta-data indicating that this file is scheduled-add on account of a merge, and thus can be removed as part of a revert of the merge. Ah, but we don't treat a WC merge as an atomic operation, and especially we don't treat reversion as atomic, we revert file-by-file. Necessarily so, since we may be reverting the combination of several manual and Subversion operations. Hmm.)

> (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.)

That example is correct because 'revert' should revert the Subversion operation which was 'svn add', not the creation of the file contents. But in the case where 'svn merge' creates and adds a file, reversion of the operation _should_ remove the file from the directory as well as un-scheduling its addition.

> 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

Anyone care to write up an entry for it to go in the FAQ web page and/or book appendix?

> if it would be nice to add another switch to 'svn revert' that tells it
> to destroy any unversioned files.

No - I believe it should only destroy unversioned files if a previous Subversion operation created them. I don't know whether that's feasible in the general case but it might be.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 1 16:30:54 2004

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.