[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Update/switch with an existing tree-conflict for move-update

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 05 Mar 2013 16:37:03 +0000

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

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:
Received on 2013-03-05 17:37:51 CET

This is an archived mail posted to the Subversion Dev mailing list.