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
