Splitting op_depth into base_op_depth and work_op_depth

philip_at_apache.org writes:

> Author: philip
> Date: Fri Oct 8 09:53:19 2010
> New Revision: 1005751
  
> + PM: Yes, we have overwrite sematics. The FS layer on the server has
> + magic that converts the copy of the r12 descendant into a replace if
> + the descendant exists in r10. The client does not send a delete.
> +
> + This magic applies to copies, not deletes, so there is a problem
> + when the descendant is deleted in the mixed-revision copy in the
> + working copy. When faced with a copy of the subtree at r10 and a
> + delete of a descendant at r12 the commit doesn't work at present.
> + Deleting the descendant is wrong if it does not exist in r10, but
> + not deleting it is wrong if it does exist. I suppose the client
> + could ask the server, or perhaps use multiple layers of BASE to
> + track mixed-revisions (argh!).

Suppose we were to split NODES.op_depth into base_op_depth and
work_op_depth, one of which is always set and one of which is always
NULL. Then we could represent a mixed revision working copy as a
layering of base_op_depth. (work_op_depth=0 might be allowed but
otherwise work_op_depth would be much like op_depth>0.)

Having layers of base_op_depth would allow us to represent a mixed-rev
copy as layers of work_op_depth and so should solve the delete problem
above. We could also used layers of base_op_depth to represent
switched subtrees, and that would probably allow us to handle deletes
of the root of the switch (as a tree conflict perhaps?). Layers of
base_op_depth would also allow us to represent externals as single
working copy: a base_op_depth=1 without base_op_depth=0 would be an
external.

This is probably not something for 1.7, I'd really like to get 1.7
released rather than spend forever redesigning it, but perhaps this is
something for 1.8?

-- 
Philip