We have several issues related to the question of how revert should
handle locally added or copied items:
'svn revert of svn move'
http://subversion.tigris.org/issues/show_bug.cgi?id=876
'svn revert should provide a way to delete copied files'
http://subversion.tigris.org/issues/show_bug.cgi?id=3101
'Case only renames resulting from merges don't work or break the WC on
case-insensitive file systems'
http://subversion.tigris.org/issues/show_bug.cgi?id=3115
With only one exception that I know of[1], revert leaves local
additions of every stripe as unversioned. My first question is
simple:
"Do we consider this the correct behavior?"
A) "Yes! svn revert only reverts the scheduled addition, but leaves
the item behind as unversioned". In this case the one exception [1]
becomes a bug which we can fix.
B) "No! svn revert should remove all additions from disk. I asked for
it after all!". In this case that one exception [1] is the correct
behavior and we need fix everything else.
C) Then of course, there is the more complex answer where we allow
revert to summarily delete additions in some cases, but not in others.
Perhaps local additions are left as unversioned, but copies are
deleted. Or perhaps in the latter case we only delete the addition if
the copy is identical to its source.
I'm wondering if there is any consensus on the 'A', ''B, or 'C'
approaches. If 'A' or 'B' then our task is straightforward. If it's
'C', then we'll need some more discussion.
I favor 'A'. I know that leaving behind unversioned items post-revert
can be a bit of a pain in some use cases (e.g. "Oh I merged the wrong
revs, let's revert and redo the correct merge, hey, what are all these
skips!?!") but I think this approach is easy to understand and explain
to users. The workarounds if someone has a problem with this behavior
are also relatively simple.
While option 'C' is tempting, I think it adds needless complexity and
probably results in behavior that is difficult to explain to users in
a concise way [2].
Option 'B' is awful IMHO. We don't expect svn revert to remove
unversioned items
(http://subversion.tigris.org/issues/show_bug.cgi?id=1424#desc3) and I
think this is quite a similar situation.
Paul
[1] As described in
http://subversion.tigris.org/issues/show_bug.cgi?id=3115#desc8, the
single-DB wcng working copy now allows us to successfully merge a
case-only file rename into a WC on a case-insensitive file system.
But when we revert such a change, the added file is deleted, rather
than left as an unversioned obstruction to the original file.
[2] My view is obviously colored by my experiences with merge
tracking, where we tried to intelligently DTRT no matter what the user
tried. This has left us with a feature that can be exceedingly
challenging to explain..."oh, so are are doing a sync merge into a
mixed revision working copy with switched subtrees and some subtrees
at depth=empty, ok we'll attempt to record mergeinfo to describe this
situation, here is what will happen...<cue novella length
explanation>"
Received on 2010-08-09 18:55:13 CEST