Setting up Subversion 1.6 Server

Bill Tudor — Mon, 13 Apr 2009 03:47:26 GMT

Subversion 1.6 was release a few weeks back, and I am finally getting around to installing on a server here. I plan to create a new repository with this install, importing older projects in as required. I will be installing into a virtual machine instance, since they are easier to manage and move around.

Downloads

I downloaded the (free) subversion components from Tigris.org:

Windows Binaries (as a simple ZIP file)
TortoiseSVN as an MSI installer
ankhSVN as an MSI installer

These files were placed (staged) in a shared folder on the server so that I can easily install on various clients around the network. The “Windows Binaries” download contains both the server side and the client side command-line tools. TortoiseSVN is a client-side Windows shell extension (I downloaded both the 32-bit and 64-bit versions). ankhSVN (I always forget what that stands for – the name should be changed if you ask me) is a Visual Studio integration package for vs2008. Note that this component, at version 2.1, is not yet in final release form – I had to download the latest daily build to get subversion 1.6 support.

Server Install

There is no “installer” for the server install. Yes, I know there are people out there with “server packages” to download – some are even free - but it is just as easy to do it all yourself. Here are the steps I took:

Created a folder named “Tigris Subversion” under the Program Files folder
Changed permissions to: Administrators:Full, [ServiceAccount]:Full, Users:Read
Copied in the folder “svn-win32-1.6.0”, which is just the un-zipped distro package

Note: I plan to use a special [ServiceAccount] user to run the subversion server service so that user can be setup with proper security rights. By this I mean the user can read/write the subversion repository, log on as a service on the server machine, and very little else (no rights anywhere else on the network).
Create/register a service with the Service Control Manager (SCM) using the command:
sc create svnserver binPath= "C:\Program Files\Tigris Subversion\svn-win32-1.6.0\bin\svnserve.exe"
Use “regedt32” to modify the service entry to include --service -r "C:\Program Files\Tigris Subversion\repository" on the command line, Tcpip as a “depends on” service, and startup set to Auto (last two items not critical).

Note: Step 5 can be done along with step 4 assuming you know how to use the “sc.exe” command properly. I can never figure it out, particularly when there are spaces in the pathnames, so editing the service entry in the registry is easier for me.

Create Repository

Run the command: svnadmin create "C:\Program Files\Tigris Subversion\repository"
Edit the file “svnserve.conf” in the repository folder; turn on username/password.
Edit the file “passwd” in the repository folder; add some users and passwords.

This creates an empty repository in a folder named “repository” in my installation area. For added security, I then removed the Users:R permission completely from this folder. Only administrators and the special TFSService account can access the repository, which includes the source code as well as the password and configuration information.

Final Steps – Running the service

Punch a hole in the firewall for Tcp port 3690. I set the scope of the firewall inbound rule to “local subnet” since I do not plan to come in over the internet. If I did plan internet access, I would probably run subversion server under Apache and come in using port 80. I do not know how to do this, as I have never attempted to do so. The “SVN” protocol over port 3690 is perfect for a little LAN. (and super-fast, too).
Start the service using “net start svnserver” (or whatever you called the service), or using the Services MMC snap-in.

If all goes well, you will have an SVN server running as a service on port 3690. Check the task manager. View ports on “netstat –a ”. The subversion server process is pretty light-weight, clocking in with a mere 3Mb working set.

You can run more than one server (on different Tcp ports), to serve up more than one repository.

Testing the Install

A quick test: run the command svn info svn://localhost on the server. The response let’s you know everything is working. Well, almost everything. We can’t test the firewall settings until we move over to a client. In any case, we can log off the server now. Time for client installs.

Client Install

I recommend using both the free Explorer shell extension (Tortoise SVN) and the free Visual Studio integration package (ankhSVN).

Run the MSI installer for Tortoise SVN
Run the MSI installer for ankhSVN

Once installed, I like to change the Tortoise SVN settings to perform “Icon Overlays” only on my planned SVN workspace folder. To do this, choose settings from the Tortoise SVN context menu, available with a right-mouse on virtually any file or folder in Windows Explorer, and set the exclude path to “*” and include paths appropriately under the “Icon overlay” section. I don’t normally change anything else. The SVN icons are a bit cheesy, if you ask me. Must be the lack of open source designers.

As for Visual Studio, the Subversion add-on functions just fine along side Team Explorer (TFS Client). You just have to remember to change your current Source Control Plugin in Tools|Options from time-to-time when working with different projects that are controlled under the different systems. I have not run into any issues.

To access your subversion server, just use the URL “svn://servername” and the username/password you setup earlier. Both clients cache this information locally, so you typically only have to enter it once.

Final Thoughts

Overall, not too difficult. Of course, you don’t really need a separate server machine – you can run svnserv.exe right on the client machine, and store the repository on local disks, removable disks, or a network share. I like using a server, however, so that I can primarily work on my desktop machine but can quickly checkout a source tree on the laptop, go on the road, and sync up all the changes with a commit when I get back home. [This process works equally well with Team Foundation Server’s new “work offline” feature introduced in vs2008].

There’s a lot to like about subversion, particularly if you only need source control. It’s perfect for my setup, here.

One gripe I have with Subversion on Windows is that it does not (to my knowledge) integrate with Active Directory, therefore you have to maintain an “alternate” username/plain text password file system. There may be other ways to handle this, but I am not aware.

My Approach:

Lock down the passwd file, allowing only [ServiceAccount] and administrators access.
Create users
Use reasonably strong passwords
Never use Windows account passwords

Subversion clients cache login information so lack of integration with Windows Authentication is really not much of a big deal after all.