> You've provided lots of detail (thanks!), from which I can tell that the
> failed commit has somehow been recorded in the revisions database, but its
> record in the transactions database is missing. It's hard to say how this
> corruption happened, or why the original failure occurred.
>
> Was anything happening to the server which could have caused the failure?
> I'm afraid it seems likely that the cause will remain a mystery :-(
The last commit for 13211 was at 18:50, the server was rebooted at 19:10.
The reason it was rebooted was because of some problem with the graphics
card, and it was hard reset rather than shutdown. I would think though the
db files had been flushed by then.
> > It looks like svnadmin hotcopy doesn't detect the error which implies I
> > could overwrite a good backup with one that has problems and not know it
> > unless I also do verify every time? Or is there a better way of doing
it?
>
> Unfortunately, this is quite correct. Hotcopy only verifies that the
result
> is a valid to Berkeley DB. It doesn't check that the data stored within
the
> Berkeley DBs is valid to subversion.
The time consuming part was having to reload the repository from the dump
file, I'm now looking at FSFS as that seems to do that much faster.
What I really wanted to do though was just roll the repository back to use
that earlier revision from svnadmin, discarding the revision that's now
causing the error. I'm not losing any more than I am by having to go to the
backup, but I'd save a lot of time. I've no idea if the design could be
changed to do that, but it would certainly help once a problem has happened.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 13 02:31:13 2004