----- Original Message -----
> From: Stefan Sperling <stsp_at_elego.de>
> To: Julian Foad <julianfoad_at_btopenworld.com>
> Cc: "dev_at_subversion.apache.org" <dev_at_subversion.apache.org>; Bert Huijben <bert_at_qqmail.nl>
> Sent: Wednesday, 16 May 2012, 14:07
> Subject: Re: new conflict callback API
>
> On Wed, May 16, 2012 at 01:55:01PM +0100, Julian Foad wrote:
>> I think the way to avoid "offering options the client library is not
> prepared to handle" is that the application should resolve a conflict by
> calling a series of (mostly) normal client operations, rather than by telling
> the client library to do "the conflict-resolution-action named
> 'foo'".
>>
>> Certainly the set of available client-lib operations could include some of
> the common resolutions, but the application should not be restricted to offering
> only the options that are compiled into some list in the the Subversion library.
>>
>> It follows from what I'm saying that I don't believe we should be
> trying to make all clients display the same set of options. Instead, we should
> just show the client application authors what we think is a reasonable selection
> of options as a starting point to guide them, and let them deviate from that
> (especially by adding more interesting/complex ones).
>
> The tree conflict space is large. It is the cross product of all
> fundamental actions the version control system can perform on a local
> node (add, delete, edit, copy, move) and the same list of actions
> for the incoming change made to the node. And then for each box in
> the resulting matrix you have some number of N possible resolution
> options, to be determined on a case-by-case basis for each type of
> tree conflict.
>
> I don't think it is a good idea to leave the reasoning about any of
> this to client developers. Client developers are writing interfaces.
> They are not writing a version control system library. I strongly
> believe that the library should take extensive care of this problem.
>
> If clients decide not to use the conflict resolution API but perform
> custom API callls into the library to resolve a conflict, that's fine.
> They can already do that today and this possibility won't go away.
> But that is orthogonal to what I'm trying to do.
OK, I appreciate that issue. I see two ways the client lib can help:
1. providing a set of client-lib APIs to perform the most commonly wanted resolutions;
2. providing a set of (APIs? comments?) that suggest what set of possible resolutions to offer for a given conflict.
Does that match what you're aiming for?
- Julian
Received on 2012-05-16 15:52:41 CEST