Daniel Shahaf writes:
> My own answer to "how to change Ev2 to enable representing
> I think the above means we have to modify move() to use SRC arguments
> relative to the start state of the edited tree, rather than to its
> current state.
> If we do that, we could represent your commit as:
> mv(A/B/C, A); mv(A/B, A/B); mv(A, A/B/C);.
> While we're making changes, I wonder if we should nuke rotate(). I have
> several reasons:
I've been thinking of that as well. rotate was not it the first draft
of Ev2, it was added when I asked how to order the moves in a swap.
You have ordered these "start state" moves by depth order of the
destination, which seems reasonable. I think that implies that the
destination refers to the current state which is the same as the final
So the pair
mv(A, B) ; mv(X, B/Y)
has to be in that order while the pair
mv(A/P, A/Q) ; mv(B/S, B/T)
could be in any order.
The two moves that make up a swap:
mv(A, B) ; mv(B, A)
mv(A/X, B/C/Y) ; mv(B/C/Y, A/X)
can usually be in any order (except for the unusual case such as A/B/C
For a swap/rotate the receiver is responsible for doing something to
enable the moves to occur. I suppose different receivers could do
different things. The driver knows when mv(A,B) is part of a rotate and
when it is just a move. Perhaps it should distinguish the two and
communicate this so the receiver knows as well?
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data