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:
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:
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:
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
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
---------------------------------------------------------------------
|
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.