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.
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-09-11 20:45:20 CEST