On Wed, May 16, 2012 at 8:55 AM, Julian Foad <julianf...@btopenworld.com> wrote: > Stefan Sperling wrote: > >> Bert Huijben wrote: >>> Note that the simple view of this model doesn't match GUI clients >>> expectations. >>> >>> GUI's can stay inside a callback and keep the gui functional for other >>> operations, so callbacks can only be handled by application-modal dialogs >>> (You can't do something else). >>> >>> That is why most GUI's use svn status to determine the commit targets and >>> then pass a list of targets to the API, to specify what to commit. >>> >>> Please make sure the new api also handles these scenarios, instead of just >>> optimizing for the callback case. >>> >>> I wouldn't have a problem if at the libsvn_wc level we create a simple >>> callback that just says something like: 'This local_abspath is conflicted. >>> Resolve it now if you like'. The callback can then use the normal apis >>> to examine and resolve the conflict using the same svn_wc_context_t (and >>> svn_client_ctx_t). >> >> 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'". > > 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).
To a degree, clients can already do this. When SVN 1.6 came out we created a custom tree conflict resolution wizard for Subclipse that does this. It just runs a series of high-level SVN options to resolve conflicts in various ways. That said, I also like having built-in resolutions that we can just call. Currently, the only way to do the things that svn resolve --accept=XXX does is to call that API. I guess it would be OK if those resolutions were separate API's that we could call and then we would just follow them up with a general API call that says we have resolved everything. But again, I think we can do that today and the question is really just whether SVN could provide more API's to resolve more scenarios. -- Thanks Mark Phippard http://markphip.blogspot.com/
