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

Moves in FSFS

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 11 Sep 2013 16:21:45 +0100

While discussions continue about the "editor" and the WC side of move
tracking, I'd like to make some progress on the Repository side.

The Wiki page


declares the semantic model and


attempts to specify the changes needed. I think the model for move
semantics in the repository as presented there is pretty solid --
precise and complete and having a nice set of properties.

Can anyone review this? If anyone can take it forward in any way that
would be a great help, otherwise I'll tackle the implementation

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, 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.

Clearly it would defeat the O(1) cost if we were to construct a
node-line-id explicitly for every node in the tree at copy time. Can
we instead define node-line-id such that we can compute it as needed,
from either an unmodified lazy-copied child or after such a child has
been modified, and get the same answer? Or perhaps re-state the
problem to avoid this need?

- Julian
Received on 2013-09-11 17:22:31 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.