Philip Martin wrote:
> "Bill Tutt" <rassilon@lyra.org> writes:
>
>
>>>Which cancellation editor? Is there some mechanism already in place?
>>>Grepping the source code for "cancel" doesn't reveal anything.
>>
>>Once upon a time, (dunno if the code is still there), I had submitted a
>>patch for a cancellation editor that got composed with the update and
>>commit editors. This allowed per operation cancellation baton state to
>>be used and leveraged.
>
>
> I don't see anything obvious in the current code. I have found some
> patches in the mailing list from about nine months ago, a combined
> trace/cancel set, I guess they never made it into the code base.
it was committed at one point, but was removed some time after, i'm not
sure why.
> Well, the approach in Garrett's patch does allow an application to
> cancel on the basis of thread identity, and if the application tracks
> which operation each thread is running it can decide which threads to
> cancel.
>
> The cancellation editor approach fits in neatly with the other editor
> code. I wonder how much bit-rot your patches have suffered over the
> months? I think the trace part is redundant, but the cancel part may
> be worth investigating.
the problem with the cancelation editor (in my mind) is that it requires
the client app to know that we're using editors, and we've been moving
away from that (that's why we know longer use trace editors, now we have
callback functions). the fact that we use editors internally is an
implementation detail, and is not something that the client application
should know about or care about.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 18 17:09:08 2002