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

Stefan Sperling wrote:

> On Tue, Mar 05, 2013 at 04:37:03PM +0000, Philip Martin wrote:
>>     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.
>
> Yes!

Agreed.

>> 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.
>
> I was thinking for 1.8 we could remove skip-handling only for nodes that
> have a particular tree conflict flagged (incoming edit vs. local moved-away).
> This way, we can allow updating a conflicted move source to single-rev and
> prevent any other (unforeseen) side effects of removing the skip handling.
> I am not sure what those side effects might be. I'd just like to be careful
> about making gratuitous changes at this point in the release cycle.
> However, if it is generally safe and simpler to not skip on update at
> all, then let's do that.

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
    - "reason" is moved-away (obviously)
      or deleted directory (because it may have moved-away children) [1]
    - "action" is "edit", I assume
      (would it also make sense when "action" is "delete"?)

  * 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.

[1] 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.

- Julian
Received on 2013-03-05 18:31:31 CET