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. br...@wandisco.com
