On Wed, May 16, 2012 at 01:59:43PM +0200, 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.
Received on 2012-05-16 14:22:11 CEST