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).
- Julian
Received on 2012-05-16 14:55:38 CEST