Sigh, i used the wrong email address.
Please include steven.bosscher@gmail.com in followups as our
representative angry user :)
On Mon, 2006-03-13 at 08:58 -0500, Daniel Berlin wrote:
> > 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:06:11 2006