[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Move tracking and NODES.moved_to/moved_here

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 08 Dec 2011 10:49:28 +0000

Julian Foad <julianfoad_at_btopenworld.com> writes:

>> Now consider a further merge, it will produce a tree conflict it it
>> attempts to modify X/Y, the modifications should go into X/Z.  If we
>> record the Y->Z move then merge can avoid the tree conflict.
> Precisely -- agreed.

Another example, see move_on_move, the new test 36 in op-depth-tests.c.
Start with two nodes A and A/B, move A/B to B2 and delete A. The move
is recorded properly. Now replace A with a copy that contains another
B, that gives us another A/B that we can move somewhere else:

op_depth local_relpath presence moved_here moved_to
      0 A normal
      0 A/B normal B2
      1 B2 normal 1
      1 A normal
      1 A/B normal

If I move A/B to B3 that move gets recorded in the A/B base node,
overwriting the move already recorded:

op_depth local_relpath presence moved_here moved_to
      0 A normal
      0 A/B normal B3
      1 B2 normal 1
      1 B3 normal 1
      1 A normal
      1 A/B normal
      2 A/B base-deleted

That's probably an error in the current implementation: it should not
record moves in an unrelated base node. That's equivalent to saying
that moves inside copies (copies that are not moves) are not recorded.
As I explained earlier I think we should be recording such moves and the
obvious solution is to record the B3 move in A/B at op-depth=1.

Storing moves like that has consequences. The relpath A/B is now moved
to multiple locations: A/B to B2 and A/B to B3. It also means that to
identify the moved_to associated with a given moved_here is harder, we
should probably change the moved_here column to an op-depth rather than
a simple flag. The _scan_deletion API will probably need to change so
that it can return an array of moves.

I guess this may have implications when it comes to storing moves in the
repository, but I've not given it much though.

uberSVN: Apache Subversion Made Easy
Received on 2011-12-08 11:50:08 CET

This is an archived mail posted to the Subversion Dev mailing list.