[Paul Burba] > 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.
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. Peter
