On Mon, Sep 9, 2013 at 11:35 AM, Julian Foad <julianf...@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
