
HOWTO: Installing Subversion on ReadyNas NV+
Originally published on my old blog at cumps.be on April 4, 2009.
A little side-track from the Continuous Integration Build Server series, but still related as it’ll be part of my CI infrastructure.
A few weeks ago, I bought myself a ReadyNAS NV+ RAID enclosure and fitted it with 4x500GB in a RAID5 setup. I’ve bought this because it’s about time I started implementing a decent backup solution. Up to now I’ve been either backing up by copying to external disks, or to a RAID 1 on an old desktop. Both solutions are only half as practical. The external disks can crash themselves, while the desktop takes up a lot more space and makes a lot more noise, an issue for me since I don’t have a basement to hide things in :)
Over time I’ve also acquired more and more machines, which started making backing up things a little more complex than they should be. So, the ReadyNAS now fulfills the role of a central file server, containing all my work-related data. Each machine still has its Temp folder where I drop junk in of course, but if something is deemed useful, I give it a nice spot on the RAID.
Now, documents, pictures, drives, etc. are one thing, and were very easy to get on the RAID: drag and drop in Explorer, FTP over with FlashFXP, use WebDAV, it all works. Source code is different. I have no real ambition to develop on a remote copy of my source. I’m also too spoiled by version control to go back to a single copy.
Solution? The ReadyNAS runs Linux, I can SSH to it, and it has apt-get on it, with some outdated SVN sources however, so it has everything needed to just compile Subversion myself :)
I will not go into detail on how to create an actual repository, only on how to set up the server. In my case, I had an existing repository running on a Windows svn 1.6.0 machine which I wanted to port over. The svn book will explain in detail how to use svnadmin to create a repository.
My SVN install is only using svnserve as the server daemon: no Apache, no tunneling over SSH, as it will only run on my local LAN for now. If the need arises later, I’ll revisit this article and post an update, but for now: YAGNI. I’m also using FSFS as a backing store, no BerkeleyDB.
Starting point
- I have a share called
data. - I created 2 directory trees on there:
/Compile(will contain the SVN sources) and/Servers/Subversion/Repositories(will contain my ported repositories).
Prerequisites
Preparation
- SSH into your ReadyNAS and navigate to the folder you want to compile in (
/c/data/Compilein my case). - Get the latest Subversion source:
wget https://archive.apache.org/dist/subversion/subversion-1.6.0.tar.gz - Extract it:
tar -xvzf subversion-1.6.0.tar.gz - Get the latest APT sources:
apt-get update
Setting up dependencies
To compile SVN we need build tools (gcc, autoconf, libtool) and various third party libs. I’m getting these through apt-get.
I’m putting the commands here with the -s switch. This will not do anything, simply simulate what would happen. When you’re confident, remove the -s and run it, and select Yes when it asks to go ahead.
Out of safety (paranoia?) I’m also doing apt-get clean after each install, don’t need all the downloads lying around.
apt-get -s install gcc autoconf libtool
apt-get -s install libapr1-dev
apt-get -s install libaprutil1-dev
apt-get -s install sqlite
apt-get -s install zlib1g-dev
apt-get -s install libdb4.2-dev
apt-get -s install nano
apt-get clean
Then fix a symbolic link:
ln /usr/lib/libaprutil-1.so.0.2.7 /usr/lib/libaprutil-1.so -s -i
On my system libaprutil-1.so pointed to a non-existing version, which made the SVN compile crash.
Compiling SVN
- Go to your extracted sources:
cd /c/data/Compile/subversion-1.6.0 - Configure the sources for compilation:
./configure --build=sparc-linux --without-neon --without-berkeley-db --without-ssl - Compile SVN:
make - Install the compiled binaries:
make install
Configuring SVN
Create or copy over a repository; in my case I copied an existing repo over to
/c/data/Servers/Subversion/Repositories.Add svn to
/etc/servicesif it isn’t in there yet (it wasn’t for me):nano /etc/servicessvn 3690/tcp # Subversion svn 3690/udp # SubversionMake inetd handle SVN requests:
nano /etc/inetd.confsvn stream tcp nowait david /usr/local/bin/svnserve svnserve -i -r /c/data/Servers/Subversion/Repositoriesdavidis the user which svnserve runs under, in my case also the owner of the share. You could always create a separate svn user and svn share and set it up like that.-r /c/data/Servers/Subversion/Repositoriesindicates the root path for svnserve. This will correspond with the root level you expose to clients, and restrictive is good.Restart inetd:
killall -HUP inetd
Using SVN
On your client, open up an SVN client, like TortoiseSVN, and enter svn://yournas/yourrepo as url, and everything should work! :)
Congratulations, you can now sleep at night again, knowing your source code is version controlled and stored on a RAID.
You May Also Like

Building a Continuous Integration Build Server
A new series after the design patterns: building a Continuous Integration build server from scratch.

Upgrading Subversion
Svn 1-Click Setup turned out to be far behind. Upgrading to the official SVN 1.6.0 binaries without losing any repository data.

How This Blog Is Served
The machinery behind the words you're reading: Hugo, an unprivileged nginx, a strict CSP, and a deploy script.



