On Sat, Aug 13, 2011 at 10:41:11AM +0400, Ivan Zhakov wrote:
> On Sat, Aug 13, 2011 at 00:49, <stsp_at_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.
Received on 2011-08-13 12:14:54 CEST