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>"
