Got Subversion working on OS X again this weekend. Once again, a good fraction of my open-source projects are imported into the repository, which you can now browse “live”. When the Subversion support in ViewCVS settles down, I'll install a copy so anyone can browse past revisions via the Web as well. If you have a Subversion client, you can of course access the repository on a read-only basis. I should be keeping up with the latest Subversion, as I'm now using it to manage code for my research work as well. (That repository is not public.)
There were two causes of the repository corruption I was seeing. One was a bug with concurrent access: Berkeley DB 4.0.14 incorrectly implements mutexes on Mac OS X. Keith Bostic posted a fix, which I've applied. It seems to work well. The eventual solution will be upgrading Subversion to support a current, 4.1.x release of Berkeley DB, which also incorporates the mutex fix. Justin Erenkrantz, an OS X user and Apache/Subversion developer, has some preliminary patches to add 4.1.x support without compromising 4.0.14 compatibility.
The second cause of corruption was ra_local (local filesystem) access to the database files scrambling permissions. The repository access layer in Subversion supports multiple access methods: the two most common and mature are ra_local and ra_dav, the latter making use of WebDAV/DeltaV through the Neon library. ra_pipe, somewhat akin to rsh/ssh access for CVS, is still under development.
Berkeley DB creates logfiles as needed, each of which grows to a set maximum size before another is created. In my oft-executed repository creation script, I was very careful to set the permissions so both myself (as a local client) and remote Web users were able to access the repository. But when the first logfile filled, as I locally modified the repository, a new logfile would be created, owned by myself with permissions limited by my umask. When Apache's mod_dav_svn, running as the www user, later attempted to access the repository and couldn't read the new log file. BDB interpreted this error as indicating database corruption. Subsequent access to the database in any form failed.
Several months ago, I took this corruption warning at face value, especially when combined with the inability of db_recover to help, and simply assumed that BDB and/or Subversion needed further testing on OS X. With repeated attempts, I formalized my Subversion test script and was able to isolate the problem. As usual, it seems obvious in retrospect.
Other activities, such as performing a db_recover to fix the problem, similarly scrambled the permissions, for example removing group access to the BDB database files. The workaround for these problems is to make sure your umask is set permissively before you run a svn or svnadmin command on a local repository. If something goes wrong, as it did many times tonight, the recovery procedure is: reset the permissions on the contents of the repository's db directory, run db_recover to make BDB happy again, check the permissions again, and continue on your way.
It's unclear where, and how, this problem should be fixed. Berkeley DB should better handle permissions problems instead of generating spurious and confusing error messages. Subversion should also provide some mechanism of specifying the umask for database files: relying on the user's umask is quite inappropriate.
12:39 PM
