[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Moves in FSFS

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 11 Sep 2013 20:44:27 +0200

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. brane_at_wandisco.com
Received on 2013-09-11 20:45:20 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.