On Mon, 2003-12-29 at 15:49, Aaron Optimizer Digulla 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.
>
> Why is there no signal handler which does a rollback?
Hm, that's a legitimate question. I wonder why we are/aren't doing
this. The signal handler ought to be able to guarantee that we close
the database environment cleanly. Can another developer comment on
this?
> 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.
>
> 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.
> > Can you show us the dumpfile? Help us reproduce? There's no reason for
> > a dumpfile to "hang" in the middle of loading. It could be something as
> > simple as a database permissions problem. I doubt it's a bug in the
> > actual dumping/loading code. A "hang" is almost always a BDB problem.
> > Lots of people are ready to help, you're willing to give us details and
> > help us reproduce your problem.
>
> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 29 23:10:09 2003