Re: svn commit: r1157172 - in /subversion/trunk/subversion: libsvn_client/revert.c tests/cmdline/copy_tests.py

[Blair Zajac <bl...@orcaware.com>]

On Aug 12, 2011, at 9:05 AM, stsp@apache.org 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.

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

Blair

Re: svn commit: r1157172 - in /subversion/trunk/subversion: libsvn_client/revert.c tests/cmdline/copy_tests.py

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 12, 2011 at 09:37:57PM +0200, Stefan Sperling wrote:
> 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.

I've decided to go for this approach. See r1157246.

Re: svn commit: r1157172 - in /subversion/trunk/subversion: libsvn_client/revert.c tests/cmdline/copy_tests.py

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 12, 2011 at 11:39:17AM -0700, Blair Zajac wrote:
> 
> On Aug 12, 2011, at 9:05 AM, stsp@apache.org 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.