Skip to content


(I was learning)

git-svn on WebFaction

Getting git-svn to work on WebFaction took some time, but it was worth it to me. If you want to do this know up front that:

  • Things may not go just right. I had a lot of trial and error to get this to work. But once I got these steps figured out I have had no problem — I have removed the software and reinstalled it several times just to be sure I had it right (for me).
  • This takes time. Building from source takes a while. And if things don’t go just right and you have to re-build you’ll be even longer.

That said, mine is installed now and works just fine.

But some may wonder why all this stuff has to be installed — isn’t it on the machines already? Well, yes, but there are several reasons that it has to be install new. Most of which are permissions (remember, you’re not root) and out-of-date software on the machines. Each step will give more information as to why it is necessary.

Download, configure, install

We start by assuming that you are in your home directory (/home[n]/[username]). First, let’s make a directory to work in. It will also store your built code.

mkdir src
cd src

Also, note that I use the -s and -q options all over and never use the -v with tar. I hate all the noise, and anything important will be reported even when running things ‘quietly’ or ‘silently.’ But know that those options don’t affect your install at all.


We need to install Perl because we don’t have permissions to install Subverion’s Perl bindings to the system-wide Perl installation. Beware that this step takes a while. (Perl and Subversion are the big time suckers.)

tar xzf perl-5.10.0.tar.gz
cd perl-5.10.0
./config.gnu -q --prefix=$HOME
make -s
make install


SWIG must be installed because 1) it’s not even on the machines (at least mine), and 2) even if it was we would need to configure our own to point at our custom Perl install.

When I first installed SWIG I used the latest release, 1.3.33. Then I had to remove it and reinstall when I configured Subversion because it errored and told me that SWIG 1.3.31 is the latest supported version of.

cd ..
tar xzf swig-1.3.31.tar.gz
cd swig-1.3.31
./configure -q --prefix=$HOME --with-perl5=$HOME/bin/perl
make -s
make install

Subversion and dependencies

We must install our own version of Subversion because we need to configure and install the Perl bindings and they have to be pointed at our version of Perl.

Here is a point that this tutorial could fork — one set of instructions for 32-bit machines, and another for 64-bit machines. I am going to go through the 64-bit version because that is what I had to do and it is more work. I’ll cover 32-bit at the end.

cd ..
tar xzf subversion-1.5.2.tar.gz
tar xzf subversion-deps-1.5.2.tar.gz

Note that your ~/src directory now contains a subversion-1.5.2 directory, but not a subversion-deps-1.5.2 directory. That’s because unzipping it put the dependencies — apr, apr-util, neon and serf — inside the subversion-1.5.2 directory.


The Apache Portable Runtime must be installed because Subversion complains about the one that is already there as being too old of version. I assume you could get around this by installing and older version of Subversion, but I didn’t go that route.

cd subversion-1.5.2/apr
./configure -q --prefix=$HOME --enable-shared
make -s
make install


The Apache Portable Runtime Utility must be configured to use our version of APR.

cd ../apr-util
./configure -q --prefix=$HOME --with-expat=builtin --with-apr=$HOME --enable-shared --without-berkeley-db
make -s
make install


If by chance you downloaded your Neon separately you probably got 0.28.3, which is the version that Subverion tells you to get if you tried to configure it without Neon installed. That never, ever worked for me. But the first time I used the Neon that shipped in the deps everything worked. That version is 0.28.2.

cd ../neon
./configure -q --prefix=$HOME --with-libs=$HOME --with-ssl --enable-shared
make -s
make install


Here we start to bring it all together with our Subversion install. Note that we never installed Serf, even though it is a Subversion dependency. That’s because Serf and Neon do the same thing, which is let us use Subversion over http and https protocols. There are arguments on which is better and why, but I just went with Neon and everything is fine. If you install both Serf and Neon, Subversion will default to Neon anyway.

cd ..
./configure -q --prefix=$HOME --with-apr=$HOME --with-apr-util=$HOME --with-neon=$HOME --with-swig=$HOME --without-berkeley-db --without-apxs --without-apache --without-serf PERL=$HOME/bin/perl
make -s
make install

Once Subversion is installed we must install the SWIG Perl bindings. This is fairly straight forward. Instructions can be found in your Subversion source:

view subversion/bindings/swig/INSTALL

But here is the short ’n’ sweet version:

make swig-pl
make check-swig-pl
make install-swig-pl

I included the make check-swig-pl step just to bring up the fact that the instructions say to do it but it failed for me every time. But that failure never made a difference on the other side; everything works just fine in the end.


And we’ll finish off with our whole reason for being here — Git.

cd ..
cd git-
./configure -q --prefix=$HOME --with-perl=$HOME/bin/perl
make -s
make install

Tah-dah! Go ahead and try it out. If it works, great! If not, I am sorry, but that is the way it sometimes goes. With the information you’ve been given here and some of the possible errors (below) you will likely get it figured out.

More details


If you try to use git-svn and you get this message:

Can't locate SVN/ in @INC …

I would guess that Git and Subversion are using different versions of Perl.

If when configuring and installing Subversion you get a bunch of errors similar to this:

libtool: link: warning: `/usr/lib/gcc/ia64-suse-linux/4.1.2/../../..//' seems to be moved

Then I would guess that you are doing the 32-bit dance when you should be doing the 64-bit. (see below)

Keep your source

Don’t delete the source once you have installed — keep it! If something goes wrong and you want to reinstall you don’t want to have to configure and make all over again — a make install will do just fine.

Or if you do want to re-build you may want to remind yourself how you configured the package last time. The package’s config.log will tell you just that.


Simply skip the APR, APR-UTIL and Neon sections completely. Then swap Subversion’s configure options given above for these ones:

./configure -q --prefix=$HOME --with-ssl --with-swig=$HOME --without-berkeley-db --without-apxs --without-apache PERL=$HOME/bin/perl

With this method Subverion configures and builds its own copies of the dependencies. For some reason this method fails on 64-bit machines.


After I spent way too much time figuring out what has been covered in the main section of this article I stumbled upon little gem entitled How to install Subversion on a shared host. How I didn’t find that earlier I’ll never know. My Google-fu is pretty good but somehow this didn’t turn up ’til the end. The author and I have about the same procedure, but mine covers Git and WebFaction, while he only covers Subversion.

You may wonder why the --enable-shared option was used in almost all cases. After several failed attempts at installing I found a response on a mailing list that made me believe that it had to be used for things to work on a 64-bit machine. I didn’t want to take time to test every package with and without it, so I just used it on them all.