Greg Stein wrote on Wed, Jun 26, 2013 at 05:30:10 -0400: > On Wed, Jun 26, 2013 at 5:25 AM, Daniel Shahaf <danie...@elego.de> wrote: > > Philip Martin wrote on Wed, Jun 26, 2013 at 09:30:42 +0100: > >> Greg Stein <gst...@gmail.com> writes: > >> > >> > You're affecting six nodes, so I think you should be able to pack this > >> > down into touching 6 nodes once each. I believe this will work: > >> > > >> > move(A/B, X/Y/Z/B) > >> > rotate(A, X/Y/Z) > >> > move(X/Y, A/B/C/Y) > >> > rotate(X, A/B/C) > >> > >> Yes, I think that works. > > > > This effectively uses temporary nodes (X/Y/Z/B and A/B/C/Y). I thought > > one of the goals of Ev2 design was to not need such nodes. (This also > > ties to my thread about what state the SRC argument of move() should be > > relative to.) > > Only in Pedantic Bizarro Land. > > Come on, Daniel. There are no manufactured nodes. Those two are the > final nodes, after a bit of parent rearrangement. > > We are not making up A2 or X2, as in Philip's original email. The > commit process is not creating nodes that exist only during the txn. > All nodes survive the txn.
X2 was a temporary name. A/B/C/Y is a temporary name. Neither the name X2 nor the name A/B/C/Y survives the txn. > Well. As I said, my intuition is the "walk down the resulting tree in preorder" view. I suppose what is done here could be described as "walk the resulting tree in postorder" --- that is, at the time move() or rename() is called, the tree being moved in is at its final shape. With respect to the (/D moved from /A/C:1 ; /B moved from /A:1) example from yesterday, the solution (mv A B; mv B/C D) is not postorder, since it modifies B/C after move(_, B); but the solution (mv A/C D; mv A B) is postorder. I think the (move, move, move, rotate(6)) solution for my 9-node example is postorder, but it's hard to tell due to /X and /X/Y/Z both being move-targets inside rotate(). > Why are you being pedantic here? I see it as argumentative, rather > than constructive. :-( > Considering IRC yesterday, I wonder if you're being overly sensitive. Just to be explicit, constructiveness is my intent here. Daniel > Cheers, > -g
