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.
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?
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? 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?
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?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
