On Mon, Sep 9, 2013 at 11:35 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Branko Čibej wrote:
>> Julian Foad wrote:
>>> The design of Ev2 is based on the concept of incremental edits to a "current" tree state. I
Not really. The core/original design was "random access editing". Then
danielsh had a question about ordering, so I had to make a call.
I see no problem with saying the *source* of a copy/move is from the
original state, rather than the transient state.
>>> 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.
You say "recover", but that is an implementation issue. As has been
pointed out, that is *trivial* for the FS.
The working copy *may* receive a move() or copy() in the future, and
we can cross that bridge when we get there. I think it is a long ways
away. And when we *do* get there, I don't see a problem with retaining
original state. (hopefully, we'll have stash/checkpoint by then, and
so tossing around whole-states will be a cakewalk)
>>> 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
>>> the edit, all it changes is the timing of the information, fore-warning the consumer that a
Please don't use the term "consumer". You have a Driver, and a
Receiver. Those are the names since the beginning, and I haven't seen
a reason to try and rename those terms.
When I see "consumer", I think "consumer of the API" and have no idea
which side you're talking about. So I have to stop and look for
context.
>>> forthcoming deletion is not to be regarded as final and
>>> absolute. That fore-warning makes a sequential consumer implementation feasible.
>>
>> I think you're assuming that an implementation that doesn't keep track of the
>> initial state is simpler, or rather, "easier" to write. I don't agree with that
>> assumption. The repository already has all history available, and the WC can
>> "trivially" be taught to remember the initial state.
>
> Hmm, my comment about "makes it feasible" may have been unfounded: I agree that we could relatively easily implement a consumer that works efficiently with that scheme. In one possible implementation, purely for the purpose of illustrating whether I've understood correctly, the "delete" operation would not delete the subtree permanently until the end of the edit, and until then the subtree would merely be moved aside or hidden from the current view, but still able to be used as a move source, traced from a reference to its "initial state" path.
Yup.
But for the near future: the *only* editor receiving a move() or
copy() will be the FS editor, via a series of commit-time editors.
> I still can't shake the feeling that it doesn't match the "sequential edit" philosophy.
Some sequencing is needed for parent/child purposes.
> It seems to me that fundamentally "move away"
Never heard of it :-)
In regards to your note elsethread, you really want to call this
remember(). You would also need it for delete() operations, since a
child of a delete could be a move/copy source.
I maintain that it isn't needed. We have the original state --
trivially, in fact, in the only editor of near-term concern.
>...
Cheers,
-g
Received on 2013-09-09 22:48:34 CEST