Re: Update/switch with an existing tree-conflict for move-update
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 5 Mar 2013 17:30:56 +0000 (GMT)
Stefan Sperling wrote:
> On Tue, Mar 05, 2013 at 04:37:03PM +0000, Philip Martin wrote:
>> I've started looking at libsvn_wc/update_editor.c to see how to
Talking with Philip yesterday, my understanding was that:
* We won't start allowing updates on a text-conflicted or prop-conflicted node, because of the original reason for skipping conflicted nodes which is we don't want to design a way to record more conflicts on an already-conflicted node.
* We will allow updating a tree-conflicted node, of at least these kinds:
- "operation" is update or switch
* For other tree conflicts, we haven't thought about what would happen (at least I haven't), so I would assume we would not remove the "skip" behaviour at this stage.
 I'm not sure I understand why we need to allow updating a locally-deleted dir with moved-away children. I thought the idea was we'd require that the user first resolves the "delete" conflict on this node, and only then would we raise (or reveal) tree conflicts on its children, and at that stage we'll be dealing with a moved-away conflict.
If we don't restrict the parameters of the new update/switch, we have to deal with the fact that it might delete the node. But at least that's a well contained sub-problem, whereas trying to restrict the parameters (e.g. to just complete the update that we started) probably is a bigger can of worms because such a restriction would ripple out and be felt by APIs and UIs.
This is an archived mail posted to the Subversion Dev mailing list.