On 13 Mar 2006 16:04:48 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> Okay. For three reasons, I'm tentatively persuaded that our
> cancellation mechanism is obsolete now:
>
> One, as you point out, it's still not responsive enough, and we can't
> make it responsive enough without a massive engineering effort.
>
> Two, it doesn't leave working copies clean in many cases anyway; you
> still have to do 'svn cleanup'.
>
> Three, the main motivator for our custom cancellation callback
> originally was, IIRC, the need to protect file:// BDB repositories
> from getting wedged. Well, since that time, file:// has become less
> important -- now that Subversion is mature, a smaller percentage of
> people use it in production locally, and a greater percentage use it
> over one of the network RA layers. (I assert these things without the
> slightest data to back them up, of course. If anyone doesn't believe
> me, then I'm mortally offended.) Furthermore, 1.4 is about to have a
> much less fragile BDB integration anyway.
>
> So I might be +1 on just letting ^C do its thing without interference
> from us anymore, in Subversion 1.4. Does anyone else have thoughts on
> this? Are DannyB and I missing something important?
>
> > If you want to explain to my users why we don't die when the user tells
> > us to die, *and* we still require cleanup in some cases when we do die
> > quickly, feel free.
>
> I don't want to explain anything to your users -- I want to maintain a
> stony silence and then bill them by mail, naturally.
I still feel like we're just postponing the real solution to this
problem. There are a great many situations where you cannot simply
kill off the client when you want to cancel an operation. What
happens when you embed the client in another program?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 01:52:50 2006