Daniel Berlin <dberlin@dberlin.org> writes:
> Sigh, i used the wrong email address.
>
> Please include steven.bosscher@gmail.com in followups as our
> representative angry user :)
Okay. Hi, Steven.
On Mon, 2006-03-13 at 08:58 -0500, Daniel Berlin wrote:
> 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.
>
> [...]
>
> 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.
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.
:-)
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 00:53:33 2006