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

• APT
• EnableRootSSH

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.

Right after I posted my previous post I noticed the Svn 1-Click Setup is running hopelessly behind in SVN versions.

Their default download link is still using SVN 1.3.2 and the latest link on the download page is only at 1.4.2, and both also have an old TortoiseSVN.

That'll teach me to try out an "all-in-one" package!

Let's just build everything with official binaries from now on, and get our source control upgraded to SVN 1.6.0, without losing any data. (Since I've already checked in quite a bit in my repository)

First of all, let's get rid of the old junk!

Take a copy of your repo folder as a backup, safety first.

• Uninstall the 1-Click Setup through Add and Remove Programs
• Go to Services and stop the service.
• Open a command prompt and type sc delete SVNService
• Throw away any files left in the directory.

Time to get the good stuff in, download the latest version from subversion.tigris.org, I grabbed svn-win32-1.6.0.zip

On my machine, I have my source control layout as follows:

• C:\Servers
• C:\Servers\Subversion
• C:\Servers\Subversion\Server
• C:\Servers\Subversion\Repositories
• C:\Servers\Subversion\Repositories\Cumps

Unzip SVN 1.6.0 to the Server directory and add the bin directory to your PATH, to make future administration easier.

Copy the content of the repo you backed up to the new folder. You should end up with conf, dav, db, hooks, locks, format and README.txt in your new repository folder.

Open up a prompt and type svnadmin upgrade C:\Servers\Subversion\Repositories\Cumps, replace the last directory with your repository name. This will upgrade the repository layout to the latest. If you open up the format file in a text editor, it will say 5 as the version number.

Run the following command to create a new windows service for svn:

 
sc create SVN binpath= "C:\Servers\Subversion\Server\bin\svnserve.exe --service -r C:\Servers\Subversion\Repositories" displayname= "Subversion" depend= Tcpip start= auto

Pay attention to the single space after the equal signs!

At this point you can type NET START Svn and everything is working back as before, except you're on SVN 1.6.0 now, without any dependencies on installers and future upgrades will be a lot easier.

In the future we might upgrade this to work together with Apache too, when the need arises. Since I'm in my own private LAN, svnserve is perfectly fine, and I'm following the YAGNI (You Ain't Gonna Need It) Principle for this series.

After my previous series of post about Design Patterns, I'm planning to tackle a new subject over the course of the following articles.

We'll have a look at how to build a Continuous Integration Build Server from scratch.

I've recently dusted off an old desktop and decided to convert it to my personal build and backup server.

First things first, I won't cover the initial steps in much details as they are basic to building any server, I'll just list my starting point so you can compare.

• Windows Server 2008 Standard.
• IIS 7.
• Sql Server 2008 (this is solely because I will be running integration tests against a database).

First of all, we need a place to store our source code. I'm going to use Subversion for this, since I don't have any MSDN subscriptions lying around to install Team Foundation Server at home. (Anyone with free MSDN vouchers lying around, hint :p)

Important Update: It has come to my attention that the 1-Click Setup is outdated, read my next article on how to install the latest Subversion. I also advice to install TortoiseSVN manually with the latest version. After installing SVN, continue reading after the next paragraph on how to configure your firewall and setup your first project.

Start by downloading Svn 1-Click Setup and running the installer, I skipped the TortoiseSVN step since I already had it installed. You can install it, or get it from tortoisesvn.tigris.org and install it manually afterwards.

After installing SVN, open up the Windows Firewall Configuration and add an inbound rule for TCP port 3690 to allow clients to connect using the svn:// protocol.

Find a file called passwd in the repo directory that you created during the installation and add yourself as a user, for example:

 
[users]
david=mysuperpassword

On another machine, or locally if you want, right click somewhere in Explorer and select TortoiseSVN - Repo-browser. Enter svn://servername as a Url and press OK.

This should show you your server with one project in it. I deleted this project to end up with an empty repository.

Decide which directory will be your main working directory on your machine, right click inside it and select SVN Checkout. The default options should be all right, press OK and it will fetch your empty repository.

At this point you can create new directories below this folder and simply right click and select SVN Commit to store them on your build server.

So far for the first step in our installation of a build server, you can now already start coding and safely store your code in a source control system, where you can easily go back to different versions and branch and merge code. Have a look at the SVN Book if you want to learn to unlock the full power of Subversion.

Even when you don't follow any other steps in this series, setting up a repository on another machine would be a best practice in my eyes, and will make you sleep in peace at night :)