svn: DB_VERSION_MISMATCH: Database environment version mismatch

…or Part 2 of “Could not open the requested SVN filesystem”

Two years ago I ran into a problem with my SVN filesystem and got “Could not open the requested SVN filesystem” as the front-end error.

This appears to be an annoying catch-all error for “shit is broken with your SVN, dawg.”

Last time, it was because I had SVNPath defined in my apache’s httpd.conf file instead of SVNParentPath (when I had many repos in the same root directory.) This time I did not have that problem, but I did have the same error message.

That is annoying.

After several dead-ends, the vital kernel of information came from Mr. Mike Rooney’s suggestion to go to the host server itself and run:

sudo svn ls file:///path/to/local/repo

The two important parts here are that I’m trying to access the bjorked repo from the local filesystem, so the webdav layer isn’t being retarded at me and giving me the same enigmatic error message. The second important part here is that I’m running sudo to get past possible permission problems.

That command produced the following output:

$ sudo svn ls file:///path/to/local/repo/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/local/repo/'
svn: Berkeley DB error for filesystem '/path/to/local/repo/db' while opening environment:

svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4

At this point, I used the tried and true google-the-unique-error-message technique. After googling “svn: DB_VERSION_MISMATCH: Database environment version mismatch” (including the quotation marks for an exact search), I found this blog post that solved my problem.

Here’s the punchline:

$ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d

BUT…

The double-punchline that screwed me for a while was the fact that the berekley db utils for 4.4 were unavailable via apt-get in modern times. Thankfully, long-time systems-administration bad-ass Ted Reed was here to suggest the following set of commands:

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/libdb4.4_4.4.20-12_i386.deb
$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/db4.4-util_4.4.20-12_i386.deb
$ dpkg -i libdb4.4_4.4.20-12_i386.deb
$ dpkg -i db4.4-util_4.4.20-12_i386.deb

All of these commands (run as root or through sudo) grab the neccesary files from arcane places and got them installed. After that, the previous blog post’s wisdom could be applied. From there, I was a chmod, a chgrp, and a chown away from actually being able to access my old repository again.

Of course, this was about 10 hours after where I expected to grab my old repo’s contents…