Re: Moves in FSFS

On 17.09.2013 13:12, Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.09.2013 12:46, Philip Martin wrote:
>>> 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.
> But why does "move" need to create a new node-revision of the moved node itself (assuming the node isn't lazy-copied and isn't about to be modified). Why shouldn't it just create a new reference to the existing old node-revision? (Of course it needs to create a new node-rev of the parent directory because the parent's list of children changes.)

Becasue otherwise you can't tell there was a move without comparing
parent directory contents, and worse, you can't tell that the node was
affected by a particular commit. And I hope you'll agree the latter bit
of info is kind of important.

Note that in the current FS implementation, there is not "node" object
as such; there are only node-revision records, and the concept of a
"node" is extrapolated from the node-id, just as a branch is
extrapolated from the copy-id.

Let me reiterate: the result of a "move" in the FS representation should
be exactly the same as the result of a text or prop modification. I
believe our top-down DAG model relies on that being the case.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com