Re: Move tracking and NODES.moved_to/moved_here

"Bert Huijben" <bert_at_qqmail.nl> writes:

> The only case where you would want to track those moves, is when they are
> also stored in a different place in BASE.

Lets consider moves that do have a base node. I'm trying to determine
what is the correct behaviour for the tests nested_moves_child_first and
nested_moves_child_last in op-depth-tests.c.

Consider two nodes A and A/B and two nested moves. We can either do A/B
to A/B2 before A to A2, or A2/B to A2/B2 after A to A2. Which rows
should get marked moved_here?

State 1: after A to A2
op_depth local_relpath presence moved_here moved_to
      0 A normal A2
      0 A/B normal
      1 A base-deleted
      1 A/B base-deleted
      1 A2 normal 1
      1 A2/B normal 1

All the descendants of A2 are marked moved here. I believe this is the
way it is intended to work.

Now move A2/B to A2/B2 and note that A2/B at op-depth=1 is still marked
moved_here:

State 2: after A to A2 then A2/B to A2/B2
op_depth local_relpath presence moved_here moved_to
      0 A normal A2
      0 A/B normal A2/B
      1 A base-deleted
      1 A/B base-deleted
      1 A2 normal 1
      1 A2/B normal 1
      2 A2/B base-deleted
      2 A2/B2 normal 1

If the moves are done in the other order the result is that A2/B is not
marked moved_here.

State 3: after A/B to A/B2 then A to A2
op_depth local_relpath presence moved_here moved_to
      0 A normal A2
      0 A/B normal A2/B
      1 A base-deleted
      1 A/B base-deleted
      1 A2 normal 1
      1 A2/B normal
      2 A2/B base-deleted
      2 A2/B2 normal 1

Which of these is correct, A2/B moved_here or not? This makes a real
difference when reverting the A2/B to A2/B2 move. Reverting state 2 to
state 1 works, but reverting state 3 to state 1 doesn't because A2/B
does not get marked moved_here.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com