On Dec 30, 2003, at 4:42 PM, Aaron Optimizer Digulla wrote:
> On Mon, Dec 29, 2003 at 04:08:55PM -0600, Ben Collins-Sussman wrote:
>
>>> Thanks, that's *exactly* what I mean with "quality problem". More
>>> precisely:
>>> Is pressing Ctrl-C while the programm accesses the DB such an
>>> uncommon
>>> event? Probably not (or why is that in the FAQ?)!
>>
>> Yes, actually, it is fairly uncommon to use file:/// access at all.
>> Most people use a network to access a repository. This means that a
>> persistent server process (either apache or svnserve) is accessing the
>> repository. If a client is interrupted or disconnects, it's easy for
>> the server to just toss the work and cleanly disconnect from the
>> database.
>
> Well, I have to use file:// because I can't run a server on the
> Windows machine (no admin rights).
>
>>> Or why don't you just
>>> catch Ctrl-C and ignore it, so people cannot abort the program during
>>> fragile work?
>>
>> It's never an option to ignore a user's cancellation; if we don't
>> catch
>> the signal, users will just forcibly kill the process.
>
> Well, the signal handler could print "Aborting ... please wait.",
> cleanup the DB and then exit. While it cleans the DB, it should
> ignore all signals.
Well, it's not quite as simple as that... You can't do a whole lot of
work in a signal handler, at least not safely. What you can do (and we
do it) is set a flag so that when the main thread of control gets a
free second it can notice the flag has been flipped and begin backing
out of whatever it was doing, which includes cleaning up the db.
>>> I've seen svn corrupt the DB during file:/ and https:// accesses when
>>> I killed the client process. That should not happen.
>>
>> Let's not use the term "corrupt" -- that's not what's happening here.
>> We're talking about the database being left "open" when a process
>> suddenly dies.
>>
>> In theory, a remote client should never be able to make this happen;
>> hitting control-c during an http:// client access should not be able
>> to
>> make apache die. If it does, it's a bug in our apache code... i.e.
>> the
>> client does something that triggers an obscure segfault in apache.
>> We've see rare bugs like this before, but we have no known ones at the
>> moment. If you're able to make apache crash by using only your svn
>> client, please let us know how. We haven't seen anything like that
>> for
>> a long while.
>
> I've seen it with Version 0.23.0 (r5962). It's not that apache crashes,
> it's just that I press Ctrl-C and after that, svn hangs until I do
> a svnadmin recover (which sometimes fails as well -> need to
> dump/load).
You realize that's a positively jurassic version of svn, right? It's
quite possible (hell, certain) there are horrifically bad bugs in it
that we fixed months ago.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Dec 30 23:47:13 2003