Compiling Subversion 1.8

Getting compiled binaries is easier but sometimes it just isn’t a choice. It was 2007 when I last compiled subversion, it was still 1.4. I remember that I had a tough time figuring out the apr/apr-utils compatibility issues, and installing neon.

Now it’s 1.8. The new version deceptively gave me an impression that things has become much easier – on a CentOS 6.3 box it compiled, installed and worked with Apache 2.2 (installed by yum) perfectly! I didn’t realize it until I started checking out a repo from it. The checkout was successful but with a tiny warning – post commit FS processing had error: Couldn’t open rep-cache database.

This message was also deceptive. It made me think of permission problems. But it turns out to be a sqlite3 issue! It has the same cause with another problem – when I tried to checkout the repo on the svn server itself through file protocol, it failed with this message: SQLite compiled for 3.8.2, but running with 3.6.20.

Install with sqlite3

Since the sqlite3 version shipped with CentOS was lower than required by subversion, I downloaded the sqlite3 amalgamation, compiled it, and copied the binary and header files to correct locations. Then the configure script stopped complaining about it. I thought that fixed it but obviously it didn’t.

The correct way of installing subversion with the correct version of sqlite3 is like this:

./configure –with-sqlite=/path/to/sqlite-amalgamation/sqlite3.c

HTTP support for client

Later I noticed that the svn client didn’t even support HTTP.

Now subversion uses serf as client HTTP library.

To compile it, you need a build tool called scons. Then just follow serf’s README file.


1 comment

Leave a comment

Your email address will not be published. Required fields are marked *

Prove your intelligence before hitting * Time limit is exhausted. Please reload CAPTCHA.