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.
> > 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).
> > I'm not sure if I can reproduce the problem myself. How can I load a dump
> > which contains rev 9-13 into a DB which contains 0-9 (the first load
> > stopped during loading rev 10 and I had to kill the process)?
> >
> > Is there a way to split the dump-file? Or can I drop rev 9?
>
> Sure, you can delete rev 9 by hand-editing the dump-file. Keep the
> initial headers intact (SVN-fs-dump-format-version: and UUID:) Then
> delete Revision-number:9 all the way up to Revision-number:10.
>
> Meanwhile, can you help us reproduce by showing us the dumpfile?
After the svnadmin recover, I could load rev 10-13, so I can't
reproduce the problem anymore :-( Next time, I'll make a copy of
the DB when it happens.
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.philmann-dark.de/
---------------------------------------------------------------------
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:05:13 2003