Erik's looking at "revert" and conversing on IRC about how it can work
in the DB with op_depths. Here are my thoughts:
The semantics of a "full revert" needs to be "revert path 'X' (and all
its children recursively) back to the op_depth of its WC parent
directory". We don't need to specify the op_depth explicitly; it's
implied from the path.
But what does the granularity of a DB "revert" transaction need to be?
The granularity could be "revert just one op_depth level", and we could
apply that reversion once for each (modified) node in the tree, starting
at the deepest nodes in the tree and working progressively back to the
requested target path. That would work. Each such reversion would be
bring the WC to a new consistent state. If there are multiple layers of
directory replacement, some files might be changed on disk twice or more
times.
The granularity could alternatively be "revert all in one go, back to
the op_depth of the parent of 'X'". That would also work, and in the
case of multiple layers of replacement it could reduce the number of
disk operations to the minimum. But it's a greater complexity of
operation, and a longer transaction before the WC reaches a new
consistent state.
In my opinion, the recursive application of a single-level revert is the
better option.
In either case, how can the caller of db_op_revert() construct the work
items that will restore the correct disk nodes?
For the "one level" case, we need to be able to say "what's the pristine
version of 'X/Y/foo'?" and write a work item that deletes any item at
X/Y/foo and then creates that pristine item (which may be a different
kind, or may be 'None'). And which nodes (paths) will the tree walker
have to visit? All nodes at and below 'X/Y/foo' in the current
"working" view, child nodes before their parents. Only the "working
view", so it doesn't need to know about hidden stuff in lower layers,
other than the pristine version from just below this node.
For the "all in one go" case, we need to be able to say "what's the
pristine version of 'X/Y/foo' at the op-depth-of(parent of(X))?". The
tree walker would have to visit all nodes at and below 'X' in the
current "working" view, union with all nodes at and below 'X' in the
target op_depth. In what order would it visit those paths in order to
best change the disk while leaving unversioned nodes alone wherever
possible? Not sure.
Again, the "one level" case looks more practical to get working right.
Thoughts?
- Julian
Received on 2010-10-12 15:03:59 CEST