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.
Received on 2012-05-16 15:07:59 CEST