>From my point of view the main issue preventing 1.8 from branching is
handling partial updates of a move source as described at the end of
issue 4232 and in the XFAIL test op-depth-test.c:move_update_subtree.
The problem is as follows:
- the user moves a tree from source to destination
- the user does a partial update of the move source, perhaps an update
that deliberately affects only part of the source but more likely an
update of the whole source that is interrupted
- the user then has a move and a tree-conflict on the move source
- the user cannot resolve and preserve the move because the source is
not single-revision
- the user cannot update to single-revision because the tree-conflict
must be resolved first
To get out of this situation I think we have to allow the user to update
(or switch) the move source while the tree-conflict is present. There
is a BASE tree that we want to update but it is shadowed by a WORKING
layer either a delete or a replace. The update will generally only
modify the BASE tree, not the WORKING tree or any files (strictly
speaking it does need to add/delete presence=base-deleted rows if any
local_relpath appear or disappear).
The important point about these changes is that they are the same sort
of changes that the interrupted update would have made if it was not
interrupted. (In practice I won't restrict the new update to exactly
the same target as the interrupted update so the exact changes may
differ.)
I've started looking at libsvn_wc/update_editor.c to see how to
implement this. I'm wondering if I should remove most (all?) of the
skipping code and just leave the shadowed code.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
