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).
Received on 2012-05-16 16:17:08 CEST