Re: Move using initial state
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 9 Sep 2013 15:21:13 +0100 (BST)
Greg Stein wrote:
> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin wrote:
Let me try to lay this to rest from another angle.
Look at step 1 of that suggested sequence of three operations.† The implicit definition of the single move operation suggested there is something like:
†† "Find the subtree that was at path A/B/C at the start of this edit.
The one significant difference between the "split" (move-away, move-here) scheme and the single-move (referring to initial state) scheme can be stated like this:
† Before sending a delete operation, do we declare whether that subtree
In the example above, the first move deletes the original 'A' by replacing it.† In the second step, move(A/B_at_original, A/B) requires the edit consumer to find the original A/B, which was deleted by that earlier replacement.† In the single-move scheme, the consumer discovers this after having deleted it.
Now consider what it would mean if we amended the solution by inserting,
Overall, the edit would convey exactly the same information; no new information has been added, since that move-away was already implied by steps 2 and 3.† The only thing new is the timing of this information.† The consumer would know, before replacing 'A' in step 1, that the 'A' being replaced will be needed later.† The "split" scheme does exactly that, using the term 'move-here' instead of just 'move' for clarity.
In the "split" scheme, the consumer is informed of each move source before deleting it.† There is no other significant difference between the schemes.† (Whether the source and target are identified by a path relative to the current state or to the initial state, or given an arbitrary "id", is merely a detail of how the API semantics are codified.)
Both schemes are functionally correct.† Both schemes *could* be implemented.† But not with the same sequential temporal characteristics.
The design of Ev2 is based on the concept of incremental edits to a "current" tree state.† I feel that the idea that you could start editing the tree, deleting subtrees, and then come to an operation that says "Now please recover one of the subtrees that I earlier told you to delete" doesn't fit with that philosophy.
The model of operation of the "split-move" scheme is no more split than the model implied by the "single-move" scheme; it's just more explicit.† It doesn't in any way change or add to the overall semantic content of
Does that angle make sense, Greg?
This is an archived mail posted to the Subversion Dev mailing list.