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 on themselves can crash, while the desktop takes up a lot more space and 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 it's 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. But for source code however, I have no real ambition to develop on a remote copy of my source, not only that, but I'm spoiled by the benefits of version control that I don't want to go back to one 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 in 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.

P.S.: Shell commands are marked italic.

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/Compile in my case)
  • Get the latest subversion source: wget http://subversion.tigris.org/downloads/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
  • Fix a symbolic link: ln /usr/lib/libaprutil-1.so.0.2.7 /usr/lib/libaprutil-1.so -s -i (On my system the 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 service, if it isn't in there yet, wasn't for me: nano /etc/services svn 3690/tcp # Subversion svn 3690/udp # Subversion
  • Make inetd handle SVN requests: nano /etc/inetd.conf svn stream tcp nowait david /usr/local/bin/svnserve svnserve -i -r /c/data/Servers/Subversion/Repositories david is the user which the 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/Repositories indicates the root path for the svnserve, this will correspond with the root level you expose to clients, 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.

 
Comments: 8
 
  • Joshka

    subversion 1.6 is available in the experimental packages for debian.
    apt-get install -t experimental subversion

     
     
  • Ah well, it's up and running now exactly as I want it ;)

     
     
  • Martin

    Hi there,

    I followed your instructions and everything compiled/installed fine. However, now when I try to commit any changes using tortoise, I get the following error:
    Error: Commit failed (details follow):
    Error: no such table: rep_cache

    Any ideas on how I can use file system instead of sqlite?

    Thanks in advance.

     
     
  • I tried last week with 1.6.1 and today with 1.6.2, same result with my ReadyNAS box. I would be really interested what the reason might be.

    What would happen if I do a

    apt-get upgrade

    first. It shows me a lot of things to upgrade. Will this break the NAS?

    Thanks
    Heiko

     
     
  • Kai

    thanks for your instruction. I've got the same problem like Martin (Error: no such table: rep_cache), any suggestion to fix it is welcome...

     
     
  • Loren

    @Martin & Kai
    the rep-cache bug is a sqlite issue. I haven't gotten around to rooting through the source to figure out why the db isn't created correctly, but you can get around it by adding the line

    enable-rep-sharing = false

    in all of your /db/fsfs.conf files.

    It will be slightly less space efficient, but at least it will work ;-)

    The /dev/random issue was far more of a show-stopper for me until I figured out how to recompile apr with /dev/urandom...

    ~Loren

     
     
  • Kai

    @Loren: Great, it works! Thanks a lot for your advice!

     
     
  • Not working :(

    Hi... I'm trying to get Subversion to work... but the make already failes with:

    configure: WARNING: APRUTIL not found
    The Apache Portable Runtime Utility (APRUTIL) library cannot be found.
    Either install APRUTIL on this system and supply the appropriate
    --with-apr-util option

    or

    get it with SVN and put it in a subdirectory of this source:

    svn co \
    http://svn.apache.org/repos/asf/apr/apr-util/branches/1.2.x \
    apr-util

    Run that right here in the top level of the Subversion tree.
    Afterwards, run apr-util/buildconf in that subdirectory and
    then run configure again here.


    The problem is probably that I cannot install cause of:
    The following packages have unmet dependencies:
    libaprutil1-dev: Depends: libsqlite3-dev but it is not going to be installed

     
     
  • Leave a reply
    Items marked with * are required. (Name, Email, Comment)
    Comment is missing some required fields.
     
     
     
    To make sure you are not a computer, please type in the characters you see.