Subversion Checksum Mismatches Part 2
Posted on March 26th, 2006
In January I wrote an entry describing how to handle the "checksum mismatch on rep" error that might pop up during a dump of your Subversion repository. I ran into a corollary problem that may cause problems if you have a large repository. It's every bit as weird as the first.
After you've dumped out your repository's representations file and ferreted out the offending checksum as described previously, the next step is to load the edited file back in. You do this with db_load (or db4.2_load if you're on a Debian server). However, you may get this message:
$ db4.2_load representations < representations.dump db_load: Lock table is out of available object entries db_load: Cannot allocate memory
That sucks.
The way to handle this is described in the Subversion FAQ. The first step is to edit the DB_CONFIG file, which is right there in the db directory you're already in. Change the following values:
set_lk_max_locks 7000 set_lk_max_lockers 7000 set_lk_max_objects 7000
By default these are all 2000; what you set them to is pretty arbitrary as far as I'm concerned. The comment at the top of this file says to then run svnadmin recover for the changes to take effect. From reading this post from goldenspud.com, though, I did this:
$ db4.2_recover -v $ db4.2_recover -c -v
There's probably some redundancy there, but if you're like me and really not terribly interested in the mechanics of repairing bdb databases you won't especially care. The job at hand is to get a proper Subversion dump. Try to reload the representations file as before. Hopefully, it will go through this time.
If it doesn't, you may need to try larger values in DB_CONFIG. If you get this message:
svn: Malformed representation skeleton
then one of the MD5 strings you edited is out of whack, so you may want to start over.
After I got this mess straightened out, I created a new repository with the fsfs backend. Hopefully these kinds of problems will never pop up again.