On Sat, Aug 13, 2011 at 10:41:11AM +0400, Ivan Zhakov wrote: > On Sat, Aug 13, 2011 at 00:49, <s...@apache.org> wrote: > > Author: stsp > > Date: Fri Aug 12 20:49:09 2011 > > New Revision: 1157246 > > > > URL: http://svn.apache.org/viewvc?rev=1157246&view=rev > > Log: > > When reverting one half of a move, transform the other half into a > > plain addition/copy. > > > I think that reverting part of move is bad idea in general, but I > understand that it's needed in some cases. So ideal solution would be > block reverting half of move, but adding some kind of '--force' option > to revert it and translate to delete/copy. What do you think?
Let me explain why I think the current behaviour is best. If we want to revert both halves we have to deal with special cases where we cannot revert both halves by default (i.e. the following applies even if no --force switch was necessary to revert both halves): 1) The user wants to revert copied-half, and the delete-half of the move has been replaced. In this case we cannot revert both halves of the move without also reverting the node replacing the delete-half. 2) The user wants to revert the delete-half, and the copied-half of the move has been modified post-move. In this case we cannot revert the copied-half without also reverting the post-move textual mods. We would have to force the user to also explicitly revert the other half of the move. This can get very tedious if multiple moves are involved. And we would need to document these special cases. I would expect this would span more than one paragraph in the book. Whereas the current behaviour is easy to document in a single sentence: "If only one half of a move is reverted, the other half will be transformed into a normal copy or delete." If the new --force flag always causes a revert of both halves of the move we cannot tell if there are post-move local mods the user wants to keep. Consider what the new --force flag should mean in these cases: What if the user wants to replace the node instead of moving it? Should the user run revert --force (the replacing node is reverted) and then run rm/add? Right now, a simple 'svn revert' is enough. What if there are post-move modes in the copied-half the user does not want to move the node after all but wants to create a modified copy of it? Should the user save local mods, run revert --force (reverting the post-move mods along with the copied-half of the move), and then run 'svn copy' and modify the copied file? Right now, a simple 'svn revert' is enough. Also, consider this case: svn mv A/f B/ svn revert -R A/ The user is reverting subtree A of the working copy and may not expect B to be touched by the revert operation at all. But B/f would also be reverted (except in special case 2 above). This is a big change from previous behaviour of recursive revert of a subtree. Last but not least, trying to revert both halves of a move involves a lot more code because of the special cases we have to handle. The current approach requries only minimal changes to the existing revert code. So it is not only simpler to document but also much simpler to implement. The only gain we get from the additional complexity is preventing users from shooting themselves in the foot by reverting only one half of a move even though they meant to revert both halves, and committing the result without double-checking their commit for correctness. I don't think this gain is worth the extra effort in both the implementation and documentation.
