Re: Cancelling Subversion operations

"Bill Tutt" <rassilon@lyra.org> writes:

> Oh yeah, and what are you thinking having only one user cancellation
> handler?
> i.e. Why is this state global?

The simple answer is that it handles a global condition, namely an
asynchronous signal.

> There was a good reason that the cancellation editor was written, it's
> so that the cancellation handler could be specified for each particular
> and interesting operation.

Which cancellation editor? Is there some mechanism already in place?
Grepping the source code for "cancel" doesn't reveal anything.

> Doing it this way lets the user application maintain its state however
> it wants, and not in some bizarre way that's necessitated by
> Subversion's API choice.
>
> It just so happens that the command line client doesn't care so much,
> but other more sophisticated users of the API might.

It also happens to be fairly simple to implement. I'm not sure how a
general cancellation mechanism would work, but I suspect it may
involve passing some sort of context baton through every subversion
function. That may not be a bad thing to do anyway; I'm wondering it
it would be a better approach to the access baton stuff.

What sort of thing do you see a sophisticated API user doing when it
repsonds to an asynchronous signal?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org