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
