Re: Moves in FSFS

On 17.09.2013 13:43, Julian Foad wrote:
> Branko Čibej wrote:
>> 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.
> I assume you mean "the same" only in terms of new id assignment, not (for example) that it would necessarily create a new representation of the data content. I'd be interested to see what part of the DAG model relies on that.

Thinking about this some more, I've come to the conclusion that as far
as the DAG is concerned, we could implement ordinary moves as
parent-directory modifications. However, this would complicate the
implementation because it would have to behave differently for moves
than for other operations, and differently when the affected node is
lazy or not. Consider:

    move A/g A/h

can be represented as:

    make-mutable A
    modify A (rename pointer to child "g" to "h")

But the lazy case is different:

    copy A B
    move B/g B/h

In this case, you have to make the copy concrete before you implement
the move, or you're actually changing history; so the representation of
the move has to be:

    make-mutable B (assigns new copy-id)
    modify A (rename pointer to child "g" to "h")

(note that A is already mutable as a result of bubble-up)

While you could, theoretically, do the same thing as in the ordinary
move case, the net effect would be that the move and copy could be
recorded out-of-order in the repository history, since the copy-on-write
would probably happen eventually due to a modification od B/h. Of course
we still have the changes list that would presumably be in the correct
order, but it's IMO a bad idea if "changes" cannot be mapped to actual
structures in the DAG.

Given all of the above, we're talking about the following algorithm for
move of src to tgt (I'm ignoring parent change, for clarity):

    if src is lazy:
        make-mutable(src)
    else:
        make-mutable(dirname(src))
    modify-dir-list(dirname(src), basename(src), basename(tgt))

All of that complication merely to avoid creating a new node-revision
record. On top of the other issues (e.g., the move not being obvious
from the txn record), I hardly think this optimization is worth the
trouble. It doesn't actually gain us anything.

-- Brane

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