AW: new conflict callback API

Hi,

Von: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Stefan Sperling wrote:
> > Bert Huijben wrote:
> > So you mean that instead of calling into a GUI client via a set of
> > callbacks, the client library should provide several API functions
> > that GUI clients can use to gather conflict information and options to
> > display, once the client library calls a generic "please resolve
> > conflicts now" callback?
> >
> > In other words, keep my idea but invert the flow of control?
> >
> > I don't care much about how control flow is structured, more about
> > preventing clients from showing arbitrary conflict dialogs that differ
> > significantly from what other clients present, and which offer options
> > the client library is not prepared to handle.
>
> 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'".

I also think this is a good way to go. Some Clients may have additional semantic knowledge which helps to resolve the conflicts.

On the other hand, those clients can always decide to just skip all conflicts, and then use "svn status" and normal working copy operations to do whatever they want.

But I wonder whether it is a good, orthogonal design when the set of available conflict-resolving operations differs between "during the update operation" and "after the update operation".

I guess this is a nice topic for the hackathon, handling tree conflicts in a "nice" way is one of the next tasks in our SharpSVN-based "CoDeSys SVN".

> 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).

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915