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:
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.