Re: Moves in FSFS

On 12.09.2013 12:14, Julian Foad wrote:
> Branko Čibej wrote:
>> On 11.09.2013 17:21, Julian Foad wrote:
>>> One issue that may be harder than it sounds at first is the concept of
>>> 'node-line-id' rather than (node-id, copy-id) as the basis of the
>>> definition. The point is that when we copy (ordinary copy, not move)
>>> a directory, we lazy-copy the children,
>> No we do not. I pointed out this fallacy before. We lazy-copy a child of
>> a copied directory *when* and *if* that child is itself modified through
>> the copied parent.
> Here you simply misunderstood me. As you know, a lazy copy consists of
> two parts: first we just refer to the old id, and (later, or never) we
> copy the content and assign a new id. When I said "we lazy-copy the
> children" I meant the former; you're using the same verb phrase to mean
> the latter. I'm sorry you found that confusing. Perhaps we can both
> try to be more explicit in future.
>
> FWIW it seems to me that the first part is the lazy part of the whole
> operation; the second part is where we pay for the earlier laziness. I
> searched in Subversion's source tree, in the book, and in the World-Wide
> Web, and couldn't find any precedent for "lazy copy" referring to just
> one half of the procedure.

Right. A possibly less confusing term would be "shared representation"
and "copy on write" because that's what we actually do, depending on the
path to which the write applies.

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.

-- Brane

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