On May 13, 2004, at 5:59 AM, Ben Collins-Sussman wrote:
> Any clues as to how this happened? You weren't accessing the
> repository over a network filesystem, right?
My first clue that something was wrong was that a commit failed. It
couldn't commit a diff on some file because the version my checkout
wanted to diff against (28) didn't exist in the repository, which later
seemed to be consistent only up to revision 25.
I'm the only user of the repository, by file: or svn+ssh:, so unless
there was a zombie task poking the repository it should be safe for me
to do things to it. I use file: within the server machine and svn+ssh:
elsewhere.
I think the first thing I tried was `svnadmin recover`. It failed with
some 'run recover' message. Ironic eh? Then `cd repo/db; db_recover`,
but I got essentially the same message. At this point I am unhappy with
BDB, it has done shenanigans like this before.
One thing that worked before was to move aside the log.0000000nnnn
files and run recover. I archived away a copy of the repository, and
then did this. db_recover now completes without comment. All svn
actions fail complaining about how they can't find some "transaction
'x'" that they're looking for. So I guess BDB got consistent but only
committed some fraction of what svn is looking for.
I still have the archived and broken repositories, but have resumed
development on a repository reconstituted from a dump (which lost the
last 5 revisions).
Brian Olson
http://bolson.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 14 17:52:22 2004