Re: Moves in FSFS

On 17.09.2013 12:46, Philip Martin wrote:
> Branko Čibej <brane_at_wandisco.com> writes:
>
>> On 13.09.2013 11:32, Philip Martin wrote:
>>> Branko Čibej <brane_at_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. brane_at_wandisco.com