[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

    http://wiki.apache.org/subversion/MoveDev/MoveDev#Move_Semantics

declares the semantic model and

    http://wiki.apache.org/subversion/MoveDev/MovesInFSFS

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

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.