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