Philip Martin wrote on Thu, Jun 27, 2013 at 17:47:54 +0100:
> Daniel Shahaf <danielsh_at_elego.de> writes:
>
> > My own answer to "how to change Ev2 to enable representing rotate(A,A/B/C)":
> >
> > 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
> state.
>
+1. The current state == the final state due to the Once Rule: every
node is the destination of exactly one editor call.
> 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.
>
+1.
> The two moves that make up a swap:
>
> mv(A, B) ; mv(B, A)
>
> or
>
> 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
> above).
>
> 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?
>
That assumes the driver can efficiently detect rotations. If you
consider the rotation .../A -> .../B -> &mdots; -> .../Z -> .../A (where
the "..." part is a different parent dir each time), I think the driver
would have to walk the entire chain (in just one direction, though) to
determine that. It does seem reasonable to assume that all drivers will
have "moved from" information, at least, so we're reduced to O(N) for a
cycle of N nodes. Would we pay that cost just once per cycle?
Looking ahead, "moved-to" information should be cheap too, for drivers
that support move() as a first-order operation. (i.e.: it's not cheap
in the current server code, but it will likely be cheap in any FS layer
that supports move() as a first-order operation).
And back to your question: I don't see immediately how "move(A,B) is
part of a rotate" would be useful. I can see how "I will later move B
somewhere" may be useful and how "I won't refer to B again in this edit"
may be uesful. I suppose "I will later move something into place as .../A"
may also be useful at the time B is reached (the alter_dir(dirname(A))
call already includes similar information, but happens at a separate
point during the tree crawl).
Daniel
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
> www.wandisco.com
Received on 2013-06-27 19:34:29 CEST