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. > which means each child keeps > its old (node-id, copy-id) unless and until it is modified. That's > great for achieving the O(1) copy, but for move-tracking purposes each > child needs a unique "node-line-id" so its life-line can be uniquely > traced forward and back between this revision and a later revision by > which time it may have been modified and thus assigned a new copy-id. I still don't understand why you think you need that behaviour. An object's "life-line" can already be "uniquely traced forward and back." I think you simply have to stop thinking of a directory copy as if it actually creates copies of its children. What it does is make them visible via a new FS path, but that does not affect the children themselves. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
