On Fri, Aug 12, 2011 at 11:39:17AM -0700, Blair Zajac wrote: > > On Aug 12, 2011, at 9:05 AM, [email protected] wrote: > > > Author: stsp > > Date: Fri Aug 12 16:05:15 2011 > > New Revision: 1157172 > > > > URL: http://svn.apache.org/viewvc?rev=1157172&view=rev > > Log: > > Make 'svn revert' error out if only one side of a move is reverted. > > I actually find this useful sometimes, to revert one part of the move.
We could make the working copy forget that a move took place if only one half of a move is reverted. The current plan is to revert both sides of the move if no other local changes prevent this. The rationale is as follows: What if people accidentally revert one half, commit the other half, and later realise their mistake? The move is now a copy+delete that spans multiple revisions. I anticipate that eventually the server will communicate moves to the client. If, say, the client asks for delta -r10:40, and a sequence of moves A->B->C->D has happened within this range, the server will tell the client "A was moved to D". If the client selects a smaller range, the server might instead say "A was moved to C". Now, if any copy+delete didn't happen within a single revision there are ranges where one half of the move appears but the other does not. This is can be irritating and prevent some kinds of tree-conflicts to be handled automatically depending on merges are driven (i.e. how merge-tracking splits up revision ranges). So I think we should try to prevent a move from spreading across multiple revisions. However, clearing move-info if one half is reverted is simpler to implement because we don't have to deal with cases where we cannot revert the other half without destroying other local changes (e.g. a file replacing the delete half of a move). The behaviour is also much easier to explain because there are no special cases. Hmmm... I'll think about it. Thanks for raising this concern. > > For now, 'revert' and always refuses to incompletely revert a move. > > This will later be extended so that both sides of a move are reverted > > if no other local mods affect the moved nodes. > > Later is by 1.8? Well before then. By 1.8 I hope to be done with all subcommands that can or need to be changed to take advantage of support for local moves.
