After a routine "apt-get upgrade" of Debian testing, I found myself unable to use my Subversion repository. I got an error message when trying to commit a file:

svn: Berkeley DB error while opening environment for filesystem db:
DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.3 doesn't match environment version

A note from the Subversion FAQ had this to say:

After upgrading to Berkeley DB 4.3, I'm seeing repository errors.

Normally one can simply run svnadmin recover to upgrade a Berkeley DB repository in-place. However, due to a bug in the way this command invokes the db_recover() API, this won't work correctly when upgrading from BDB 4.0/4.1/4.2 to BDB 4.3.

Use this procedure to upgrade your repository in-place to BDB 4.3:

• Make sure no process is accessing the repository (stop Apache, svnserve, restrict access via file://, svnlook, svnadmin, etc.)
• Using an older svnadmin binary (that is, linked to an older BerkeleyDB):
  1. Recover the repository: 'svnadmin recover /path/to/repository'
  2. Make a backup of the repository.
  3. Delete all unused log files. You can see them by running 'svnadmin list-unused-dblogs /path/to/repeository'
  4. Delete the shared-memory files. These are files in the repository's db/ directory, of the form __db.00*

The repository is now usable by Berkeley DB 4.3.

As the instructions note, you need a copy of subversion linked with a pre-4.3 version of the Berkeley database library. Subversion uses Berkeley via the APR Library. So we need to install appropriate verions of Berkeley, APR and Subversion.

My notes are below. Note that I installed the APR and Subversion software into a local directory (/home/mk/proj/svn_db/local in my case). Also, my Subversion repository is in /data/svnroot.

# export LD_CONFIG_PATH=/home/mk/proj/svn_db/local

# wget 'http://downloads.sleepycat.com/db-4.2.52.tar.gz'
# tar -xvzf db-4.2.52.tar.gz
# cd db-4.2.52
# cd build_unix
# ../dist/configure
# make
# make install

# wget 'http://archive.apache.org/dist/apr/apr-0.9.5.tar.gz'
# tar -xvzf apr-0.9.5.tar.gz
# cd apr-0.9.5
# ./configure --prefix=/home/mk/proj/svn_db/local
# make
# make install

# wget 'http://archive.apache.org/dist/apr/apr-util-0.9.5.tar.gz'
# tar -xvzf apr-util-0.9.5.tar.gz
# cd apr-util-0.9.5
# ./configure --prefix=/home/mk/proj/svn_db/local --with-apr=/home/mk/proj/svn_db/local --with-berkeley-db=/usr/local/BerkeleyDB.4.2/

# make
# make install

# wget 'http://subversion.tigris.org/downloads/subversion-1.2.3.tar.bz2'
# tar -xvjf subversion-1.2.3.tar.bz2
# cd subversion-1.2.3
# ./configure --prefix=/home/mk/proj/svn_db/local --with-apr=/home/mk/proj/svn_db/local --with-berkeley-db=/usr/local/BerkeleyDB.4.2/
# make
# make install

# su
# /home/mk/proj/svn_db/local/bin/svnadmin recover /data/svnroot
# tar -cvf ~/svnroot_backup.tar /data/svnroot

Then I executed steps 3 and 4 from the FAQ. At this point, I was able to commit files to my repository again.

Link to story

Technorati tags for this post: programming subversion database linux Tech

Tools, tools and more tools for the codemonkey! Here's a little summary of some of the tools I've been using lately.

SCM and Web Tools:

• ViewCvs: We all love doing "cvs log file.C | more" and then "cvs diff -r1.12 -r1.13 file.C", but I admit that it's really nice to be able to browse the history of your project online. Viewcvs works with cvs and subversion and is used by no less an authority than sourceforge.net.
• Enscript: I discovered this as it is used by viewcvs to syntax highlight and color code for online viewing. I tend to use it like "encript --language=html --highlight --color=1 -t 'Logger.C' -p Logger.html Logger.C".
• eSVN: a really nice looking GUI frontend for subversion.
• GraphViv defines a little language for describing graphs (DAG's and the like). There are utilities for converting the descriptions to beautiful images. See the gallery for examples. GraphViz is so pretty I'll be on the lookout for interesting datasets just so I can graph them.

Code Auditing Tools:

• Flawfinder and Splint are static program checkers that flag uses of "unsafe" functions (like strcpy). I wish the use of tools like this would become common during development.
• http://www.daemonkitty.net/lurene/papers/Audit.pdf: OpenBSD continuously audits its codebase, fixing bugs. When a new bug, or class of bugs is found, the entire code base gets re-audited looking for other instances of the bug. There's wisdom in that! We all know about buffer overflows and string format bugs, but what else have the OpenBSD team been fixing? Certainly you could review the security patches they've issued, or watch the changes to the HEAD of their CVS repo. The paper above is a shortcut: it lists the major flaws found in OpenBSD software.

Technorati tags for this post: Tech programming subversion security