On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote: > 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? >
Not quite. I am aiming for extensive coverage, not just the "most common" cases. The resolver should be good enough to handle any conflict people might run into, and offer all reasonable resolution strategies for a given conflict. We won't get there in one day, of course. It will evolve with time. There should be no reason for client UIs to implement custom resolution strategies. Any such strategies belong into the core. If UI developers have a special need they should talk to us and ask for a change in the resolver if need be. The current situation is too fragmented and confusing. I don't think it helps our users if every client developer keeps reinventing the wheel. That just leads to inconsistent behaviour and indicates a deficiency of the core library. So, the APIs should present the supported options, and then act upon the choice made by the user. I don't see why you would want to split these APIs into two separate categories. They belong together. As I mentioned, if clients still want to mess with conflicts on their own using any of the existing APIs, they can do so. We won't force client API users to run the resolver, just strongly encourage them to do so. Note that all of this will run during an offline resolve, *not* during the current interactive conflict resolution during update/merge. I intend to remove interactive conflict resolution during update/merge for 1.8 and make 'svn resolve' handle all conflict resolution instead (at least to the same degree as interactive conflict resolution in 1.7, if not better).
