Re: [PATCH]: Let users cancel out of command line client immediately if they signal 3 times

> And it
> would do nothing to help programs other than our command line client.
>
Which are the only people that i have heard complain, and many times. :)

Our IDE developers seem happy with the level of cancellation support we
have.

> Thus, I still think just inserting more cancellation checks is the
> best answer.
Up until what point?

On a tree of 15k files, and when the network server can take up to 20-30
seconds to respond to things because of the size of the repo, almost any
function we do will need cancellation checks in order to maintain
interactivity.

> Had you tried that and found it difficult,
> or was it
> just the IRC conversation that put you off?

For GCC's needs, i have found it difficult.
I used to believe cancellation checks were the right answer.

On a repo and working copy of this size, you end up needing cancellation
checks pretty deep in places we don't pass the cancel func in batons
right now.

Try:

svn diff http://gcc.gnu.org/svn/gcc/branches/improved-aliasing-branch
http://gcc.gnu.org/svn/gcc/trunk

Try to cancel it immediately, and see how long it is before you can.
On my machine, it takes more than 30 seconds.
(If this becomes too fast due to server side caching, you can pick
another thing from the branches subdir and try that)

Last i looked (admittedly, 2 months ago), it required rev'ing two public
API's and hacking up a ton of functions just to fix this single problem,
and it ends up not helping the next problem at all.

There are a ton of operations, some network related, some not, which are
not cancellable for 30+ seconds on the gcc repo and working copy.

In addition, I no longer believe cancellation function checks everywhere
are the answer to a user's question "Why can't I kill the command line
client immediately with ctrl-c".

It doesn't actually solve the problem in all cases, and having
operations cancellable is orthogonal to being able to kill subversion
with ctrl-c like every single other application they have.

We can't make every expensive operation cancellable without needing
cleanup afterwards, and don't do so anyway. Commit will leave locks,
for example.
In these cases, there is no real advantage to cancellation checks here
for a command line user

They are useful for IDE developers, sure. But they aren't complaining.
It's the command line client users, who are complaining, and rightly so.
We have decided to act unlike every other command line application they
have, for no real advantage to them (since, again, some cancellations we
perform require svn cleanup anyway, like commit).

IMHO, it's not the answer for the command line client.

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 have copied one of them on this email.

--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 13 15:00:18 2006