Dave Camp wrote:
> I tried the following:
>
> # cd foo/db
> # /usr/local/BerkeleyDB.4.2/bin/db_recover -c
> db_recover: Ignoring log file: log.0000000002: magic number 0, not 40988
> db_recover: Invalid log file: log.0000000002: Invalid argument
> db_recover: First log record not found
> db_recover: PANIC: Invalid argument
> db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database
> recovery
>
> At this point, I've given up. The repository was brand new (we just
> switched to subversion on Monday) so starting over wasn't a big deal.
> However, it is somewhat distressing that the database can't be fixed.
> I was under the impression that the journalling was supposed to
> prevent that... especially considering that the file system it's on is
> journaled as well (Mac OS X Server with HFS+).
I've heard about almost exactly this problem several times recently, and
the common denominator is OS X. Two people even claimed that the last
access to the repository was an hour before the crash, and the
repository still became corrupt. I would say that such a thing is
impossible, but when it has happened twice I'm not so sure...
When I see problems such as this one, I usually fix them by removing the
__db.* and log.* files in the db directory of the repository and then
dump and load the old repository into a new one and copy the contents of
conf/ and hooks/. The dump+load is *probably* not necessary, but it's safer.
Try to upgrade to 1.1.0 and use FSFS (svnadmin create --fs-type fsfs
repos) if at all possible.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 13 13:30:15 2004