On 17.09.2013 12:46, Philip Martin wrote: > Branko Čibej <br...@wandisco.com> writes: > >> On 13.09.2013 11:32, Philip Martin wrote: >>> Branko Čibej <br...@wandisco.com> writes: >>> >>> There is another aspect to the lazy-copy which is when does the new >>> copy-id get assigned to the lazy children. If we commit >>> >>> move A/f A/g >>> >>> then move does not allocate a new copy-id and A/f has the same copy-id >>> as A/g. I think we intend this to be true if the commit combines a move >>> and a modification to the node. Now commit: >>> >>> copy A B >>> >>> here B gets a new copy-id and lazily copied children of B still have the >>> old copy-id. Now what about this commit: >>> >>> move B/g B/h >>> >>> Does move preserve the copy-id so that B/h is still a reference to A/g? >> A move through the copied parent has to be interpreted as a write to the >> subtree, which means that the copy-on-write semantics kick in. The move >> then breaks down into: >> >> make-mutable B/g <-- lazy copy, assigns a new copy-id >> move B/g B/h <-- move semantics, B/h keeps same copy-id >> >> You'll not that "make-mutable" is an implementation detail of the >> top-down DAG FS model, and it already does what I described above. This >> is not some new code we'd have to write to implement moves this way; we >> just have to obey existing rules, i.e., before operating on a path >> within an FS transaction, the path must first be made mutable. In other >> words, the FS implementation already works the way I described, >> regardless of whether the actual operation is "move" or something else. > I still don't understand. For a change like a text edit we always call > make-mutable and it always gives a new id, either changing the > revision-id or the copy-id. It's not clear to me that there should be a > make-mutable call before a move.
The result of a move needs a new revision-id. Of course you have to make the node mutable before you modify it, and "move" modifies the node in the sense that it creates a new node-revision. In the normal case, it creates a new node-revision instance, with same node-id and copy-id and new revision-id; in the lazy case, it also generates a new copy-id. In other words, it behaves exactly as a regular text or property modification. Note that make-mutable also takes care of directory bubble-up in the current top-down DAG model. > I started with a move: > > move A/f A/g > > There is no lazy copy here and I thought the plan was that a move would > not change the id, so A/g would be a reference to the same node as A/f. > Is there a make-mutable call here? Of coruse there is, but because A/f is not "lazy", the make-mutable step will not generate a new copy-id. > The next move is after lazy copy: > > move B/g B/h > > You say there is a make-mutable call here and B/h has a new copy-id. If > the move was combined with a text change the make-mutable is required, > but is it required for a move alone? Yes. Otherwise you break the model. A move after a copy refers to the copied node, so you have to unlazify the copy (apply copy-on-write) before applying the move. > Suppose I had committed a text > edit to B/g before moving it to B/h. The text-edit would have called > make-mutable and allocated a new copy-id. Would the subsequent move > above still call make-mutable? make-mutable has no effect on a mutable node. I don't recall whether we try to avoid multiple calls to make-mutable, or just make the call and not worry about nodes already being mutable. In any event, the end result shoudl be the same: a mutable node-revision in the current transaction. > Suppose I make a third move: > > move B/h B/i > > I assume this move is like the first move and it doesn't change the > id. Is there a make-mutable call here? Yes, there always is. You can even do this in the same transaction as the "move B/g B/h", and the make-mutable will be a no-op and B/i will retain the copy-id that was originally assigned when B/g was made mutable. If you do this in a separate transaction, it's exactly as the first example, "move A/f A/g". -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
