Re: Move tracking and NODES.moved_to/moved_here

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
http://www.uberSVN.com