Re: Moves in FSFS

Branko Čibej <brane_at_wandisco.com> writes:

> That said, I still do not understand why a different ID would be needed
> before the copy-on-write happens. Is it because the client doesn't have
> the full history available? If that's the case, I suggest we explore
> this on a case-by-case basis, including determining how the initial
> state of a working copy for each case can actually occur.

Is the FS going only able to provide the moves that apply between two
consecutive revisions? Or is it able to provide the combined moves
between arbitrary revisions?

One way to provide the moves between arbitrary revisions is to iterate
through the intervening revisions accumulating and combining the moves.
That has the potential to be slow.

Another way to provide the moves between arbitrary revisions is to have
an id to path map per revision which allows the FS to find the path
associated with a given id. However with lazy-copy this map is harder
to implement.

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?
If the commit was a combined move/modification then B/h would have to
get a new copy-id.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*