Re: [PATCH] Update and switch APIs call conflict resolver at end of operation

--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
----- Original Message -----
> From: Mark Phippard <markphip_at_gmail.com>
> To: Julian Foad <julianfoad_at_btopenworld.com>
> Cc: "bert_at_qqmail.nl" <bert_at_qqmail.nl>; Stefan Sperling <stsp_at_elego.de>; Subversion Development <dev_at_subversion.apache.org>; Stefan Küng <tortoisesvn_at_gmail.com>
> Sent: Wednesday, 27 March 2013, 12:31
> Subject: Re: [PATCH] Update and switch APIs call conflict resolver at end of operation
> 
> On Wed, Mar 27, 2013 at 12:22 PM, Julian Foad
> <julianfoad_at_btopenworld.com> wrote:
>>  Discussing the behaviour of the backward-compatibility APIs:
>> 
>> 
>>  Bert wrote:
>>>  I don't think the strict ordening will be a problem for old clients 
> at the
>>>  client level. We don't promis ordering in the ra layers anyway and 
> we have
>>>  changed the ordering many times before. As long as we call the 
> callbacks I
>>>  think clients would be fine. And it will solve the existing problem of
>>>  broken operations when the network layer times out on a long callback
>>>  invocation.
>> 
>>  I am not concerned specifically about the *order* of the notifications, but 
> rather the *kind* of notifications.  The notification callbacks are now going to 
> have their status field set to (the API representation of) 'conflicted', 
> like this (showing the output from 'svn' just as a way to represent what 
> happens in the API):
>> 
>>    $ svn update --accept=mf
>>    Updating...
>>     C   wc/A2/B
>>     C   wc/A2/mu
>>    Resolved conflicted state of 'wc/A2/B'
>>    Resolved conflicted state of 'wc/A2/mu'
>> 
>>  An old client expecting notification status 'updated' or 
> 'merged', like this:
>> 
>>    $ svn update --accept=mf
>>    Updating...
>>     U   wc/A2/B
>>     U   wc/A2/mu
>> 
>> 
>>  ... may be confused if it actually looks at the notification status rather 
> than merely displaying it to the user.
> 
> Just setting aside API users for a minute.  Is the first example above
> what the command line will show?
Yes.
> If we are happy with that output for command line users, then as an API
> user I am sure I can make it work for me.
> 
> As a command line user, I am not sure what I think.  I imagine some
> users will be confused by this and ask questions about the behavior.
> But it also makes sense to me, so I do not personally think it is
> something I would be hung up on.
I want to make some improvements to the command-line output.
First, I don't like the arbitrary ordering of resolver callbacks.  For a pre-specified resolution, the order in which the updates arrived (so the order of the 'C' notifications) would be better.  For interactive resolution, either that or preferably lexicographical order of the pathnames would be better.  It doesn't matter in a trivial case like I showed here where there are just two files, but for interactive resolving of say 20 conflicts I would like my brain to be able to context-switch into one subdirectory at a time rather than jumping from one path to another at random.
Since the API doesn't know whether the callback is for interactive resolution or not, I propose to sort them into  lex. order of paths.  Even if there are thousands of conflicted paths, this step should take insignificant time compared with the total update/switch/merge operation time.
Second, we can improve the output shown above, for pre-specified resolution, by making the 'Resolved' lines say what they actually did and why, perhaps like this:
>    $ svn update --accept=mf
>    Updating...
>     C   wc/A2/B
>     C   wc/A2/mu
>   Resolving all conflicts as 'mine-full'...
>    Resolved conflict on 'wc/A2/B'
>    Resolved conflict on  'wc/A2/mu'
> If we are happy with this behavior for the command line output, then I
> am OK with it at the API layer.  Thanks for the example though.  I do
> now have a better understanding of the question.
OK, glad to hear it.
- Julian