5 Critical Steps for Implementing a Subversion Server

by Bryon D Beilman

Subversion (SVN) is a great tool for managing your software as well as documents and was even recognized by Forrester Research as the sole leader in the Standalone Software Configuration Management (SCM) category. For a distributed work force it can also be very valuable to provide distributed tools and documentation while maintaining a centralized authoritative copy. There are SVN clients for Windows, OSX and Linux that all work seamlessly with the same server and repository and those clients are available with GUI and command line (CLI). I have even seen articles where people try to replicate Dropbox like functionality using SVN on their own infrastructure. The flexibility and functionality of SVN is very powerful.

While we are not going to cover how to use SVN, it is important to realize that if you are going to use it and make it a core part of your business process, you want to treat it like any other critical software and architect the implementation so that it performs well, is secure, recoverable and will scale as you grow.  Fortunately, because the software is open source this all can be done very well with minimal investment. Unfortunately, like most open source software, you have to understand the configuration and implementation details well enough to make it all work and that means using Internet sources to find the specifics of what you need to do. The details of the SVN system is available via the SVN Red Book, but how you implement it is up to you. So here are 5 critical steps for implementing a Subversion server and making it enterprise ready.

1. Use the HTTPS protocol as your communication transport between client and server.
   • The SVN server can serve the repository using a number of different methods, including direct file, http, https, SVN protocol or SVN over SSH protocol.  Some organizations use file protocol and then perhaps share this repository over NFS or CIFS and the clients access the protocol directly.  The performance is typically pretty good, as it is similar to what you might have with the rest of your internal file sharing network especially if you use a high performance NAS.  This protocol, however does not support multiple sites or remote users very well as those protocols often do not perform well over a WAN link.  The SVN server (and SVN over SSH to make it secure)  is more scalable as it works well over a WAN but it doesn't provide some of the features like centralized authentication very easily and requires a VPN (or the SSH option) to allow secure remote access.
   • SVN over HTTPS provides the security of SSL with all the benefits and flexibility of a web server.  By using HTTPS protocol, it provides good performance, the ability to use centralized authentication (see item later in this article), and most of  the high availability and performance tricks that have been used by highly available web sites around the world. Because the configuration is controlled by Apache and HTTP is a well studied protocol, there are many well known methods to configure it for firewalls, load balancers, logging, authentication and backups. HTTPS is also well supported on cloud platforms and if configured properly, clients can securely commit and update information as long as they have an Internet connection.
2. Use DNS and CNames and consider making it available externally.
   • Even if you are a small organization, you should plan for success and the ability to increase your capacity and make management easy even as the number of users increase. Each client is configured with the protocol, name of the server and the repository path. An example of this would be https://wickedserver.contoso.com/svn/myrepo.  Envision that you have 50 users of this repository and one of two things happen. You decide to migrate the server to the Amazon AWS or perhaps your server dies and you need to rebuild the repository on a new machine. Now you need to instruct 50 users on how to move to the new repository and there could be considerable downtime
   • Consider instead consider making (in our example) wickedserver.contoso.com a DNS CNAME for svnserver1.constoso.com  (your real server name).  If you configure high availability (see below for more on this), all you need to do is make one DNS change and everyone will now point to the new server. If you configure SSL certificates and firewall rules to use an external domain name then you could migrate your SVN server to any cloud provider with little to no down time.  If corporate security constraints require you to use VPN and it to be served internally, this concept still applies and planning for migration or recovery will save you considerable effort down the road.
3. Use centralized authentication via AD or LDAP
   • The SVN server has a local authentication method but every time you add a new user, or someone needs to be disabled, it requires you to make changes in two places.  Using https and the Apache server methods, you can authenticate your client access via a local Lightweight Directory Access Protocol  (LDAP) or Active Directory (AD) server.  The process is very similar to authenticating any web service to LDAP or AD setting up a BIND password on the server and using the mod_ldap and mod_authnz_ldap modules along with configuring AuthLDAP* functions in Apache.
   • Doing this well will require you to set up and use specific OUs that will control access to the repository. Then you can add or subtract access via the same method you would use to  add new employees and be assured that when an employee leaves the company, locking out their LDAP or AD account will also disable their SVN access.
4. Build your SVN server as a virtual machine (VM)
   •  In most cases, SVN access is sporadic and in use only when users are checking in or out files, but as your user base grows, you may need to increase resources.  Whether you use VMware, Citrix  or Microsoft Virtual Server, the SVN server is a great candidate as a virtual machine (VM). In the VMWare environment, you can easily put the SVN server in a cluster to make it highly available or adjust CPU or memory as needed when your environment grows.   This is a best practice for most services, but making your SVN server a VM will allow a great deal of flexibility, provide fault tolerance and even create an environment that can easily be migrated to the cloud or another location.
5. Use SVN replication to provide high availability and fault tolerance
   • Backing up your SVN server and data is very important and can be done by backing up the repository with backup software or use svndump to a file or remote location and back that file up.  Using svnsync, however to create a SVN replica server is a great way to provide fault tolerance and be part of your backup strategy. It is still important to back up the repository to be able to recover from a point in time, however using SVN replica will allow easy migration or recovery in the event of a failure.
   • The server can be at the same location, across the country or even in the cloud.  Setting up a SVN replica is as simple as doing the following.
     • Set up an additional server (ie svnserver2.contoso.com), with similar server versions, configuration, SSL Certs and authentication,
     • Set up an SVN replica using svnadmin and svnsync commands, then set up a regular cron job to run svnsync commands to keep the replica up to date. The svnsync command basically repeats the transactions of the master, so all revision history is maintained.
     • This read only copy is ready to use in case there is a problem with the master and is also a very effective way to perform a migration to another location.
     • When you need to move to a new server,  change the repository UUID, then change the DNS CNAME to point to the new server and users can continue to use the new server without any client changes needed. Once you start to write to the replica it then becomes authoritative and read/write.
     • There are more complicated methods to create multi-master SVN servers, but the complexity of this configuration can be more problematic than creating an SVN replica.

SVN can be a powerful tool for your business if you are developing a product or just want a documentation repository with version control that is available for everyone. Using these 5 SVN server best practices can make a big difference in how well your server works and reduce the time it takes to manage it.  Doing those steps well can create an enterprise quality high performance SVN environment that is secure, scalable and manageable.