Re: Changing the way we do cancellation. (was: Re: [PATCH]: Let users cancel out of command line client immediately if they signal 3 times)

> I still feel like we're just postponing the real solution to this
> problem.

Which is what?

Rewrite everything so we can cancel at any time and still cleanup safely
very fast? :)

Right now, the feature is *not* designed to be cleanup-safe, nor would
such a thing be fast. It is *just as unsafe as killing the client*.

Doing something that can support cleanup fast would probably take
rewriting the way our wc works (in terms of locking, etc).

Designing such a thing may be useful for our developers. I'm really not
arguing that it isn't useful to IDE developers.

I'm simply arguing that it's not the best solution for the command line
client to use such an interface, until it exists, when a simpler method
with the same safety properties, much greater interactivity, and is more
intuitive to users, exists.

IMHO, it would also make your design goals for such a cleanup-safe
cancellation mechanism that much easier and cleaner.

It's a much harder problem to support *both*
1. Something that can satisfy the user, in a single threaded completely
response-time dependent interactive application wants
2. Something that can satisfy the user in a multi-threaded IDE where you
can probably do the cleanups in the background.

If you take away the need to design for #1 in your cancellation
mechanism, I'd argue it will become cleaner and easier to implement.

> 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?
>
Not all of our users have the same needs. We could choose one of the
signals we currently ignore completely, and specify it to cancel instead
of kill, if that is the route we wanted to take and you are worried
about such a thing. Though it's not clear what it buys you over
killing, since you have the same safety properties.

> -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 03:34:31 2006