> With only one exception that I know of, revert leaves local
> additions of every stripe as unversioned. My first question is
> "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 
> 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  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.
My instinct is C). Revert should return the wc to how it was before.
If a file's presence and contents are due only to operations performed
by svn (add-with-history (cp, mv, merge)), delete it. If the file was
created separately from svn, keep it as an unversioned file.
'svn mkdir' is a corner case, since it is really just like 'mkdir'
followed by 'svn add', and it isn't reasonable to have to keep track of
which method was used. I don't have a strong opinion whether 'revert'
should remove the directory. It hardly matters, really, because
deleting an empty directory doesn't run the risk of losing very much of
a user's hard work.
> 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.
I'm a pretty heavy user of 'svn-clean' from contrib, so yeah, this
doesn't bother me very much.
Received on 2010-08-10 04:52:40 CEST