Yesterday Eric asked me to upgrade our Subversion version from 1.2 to 1.4 in order to take advantage of the new XML responses needed by CruiseControl.rb. My first clue that this wasn’t going to be easy was that the stock yum repositories only carry version 1.2. After a little digging I found an RPM that had version 1.4, but that carried with it a stack of other RPM dependencies that I decided not to try to untangle (been there, hated that.)
My next step was to try the recommended enterprise configuration from CollabNet. I really didn’t realize what I was getting myself into, but the result was a 1.4 version of Subversion bundled with its own Apache server. Now, I’ve been tweaking our trac-Apache-Subversion deployment quite a bit to make project creation quick and properly integrated. The thought of throwing in another Apache server into the mix didn’t seem manageable, and recreating what I did with our current Apache server looked like a serious undertaking. So, “rpm –erase” and back to the drawing board.
“When in doubt, build from the source.” Building Subversion from the sources is pretty much what I’ve come to expect from the ./configure, make, make install cycle. I made sure I also downloaded the subversion-deps tarball recommended in the release notes, and followed it to the letter. The result was a broken svn client.
svn undefined symbol: SSL_load_error_strings
The Subversion server seemed to be working well behind Apache and trac, but Eric’s CC.rb builds were failing with an SSL error. I verified the error from the command-line and did some more Googling. A few hits down I ran across this post and this email thread which helped me greatly. The only thing standing in my way was a stupid bit of automation I failed to account for.
Could not read status line: Secure connection truncated
I banged my head against this one for much longer. Google failed me, rebuilds failed me. I had a thought that maybe I forgot to restart Apache after one of the rebuilds, and I noticed that it was complaining that the svn modules had already been loaded so they wouldn’t be loaded again. I had seen this in an earlier restart and just thought, “Okay, I’ll clean that up once I get this Subversion thing to work.” However, if I had bothered to look at the httpd.conf I’d have seen that my “make install” had added the correct LoadModule line pointing to the new module, but the old LoadModule was left in place pointing to the old module. The old LoadModule happened before the new one, so I was loading an incompatible module. Once I pulled out the old module there was joy in Mudville once again.