2.5. Setting Up a Subversion Server with svnserve

Subversion works best in a team environment, and for the entire team to be able to see the repository, you need to be running it on a server. There are two reasonable options for setting up this server:

• The Subversion distribution comes with a program called svnserve, which provides for quick-and-easy setup of a repository server.

• You can use an Apache 2.x web server augmented with the mod_dav and mod_dav_svn modules. This setup is more complex, but it's also more feature-rich.

There's a third option, which is to run svnserve but allow access only via a Secure Shell (SSH) tunnel. This option is only recommended for networks that are already making heavy use of SSH, and will not be covered here.

The Subversion team recommends you avoid trying to run the repository over your file-sharing system as "local" to all developers. Doing so has significant security and stability risks.

The svnserve system is easy to set up and maintain, and is recommended as the simplest way to get your source control system up and running. It has two significant limitations — both security-related — that may prevent it from being used by your group. All network traffic to and from svnserve is in clear text — svnserve has no provision for encryption of code traffic. To use svnserve for sensitive data, the server should reside on a system that is accessible only inside a VPN or other mechanism for authenticating and encrypting traffic. Similarly, svnserve uses its own authentication system, and the passwords are stored in clear text on the server (although the password transfer is encrypted). As a more minor issue, svnserve does no logging. On the plus side, it usually outperforms the Apache solution.

The Apache solution fixes the issues with svnserve. You can use any authentication system that Apache supports, and you can use Apache to encrypt network traffic. In addition to logging, the Apache module also provides for Web-based repository browsing, which is useful. The Apache configuration is far more complex, and is well outside the scope of a book on Rails. (See the Subversion resources for more details.)

You can get svnserve running with the following command (it's recommended that you run this command under a user account that has access to the Subversion directories, and only the Subversion directories):

$svnserve -d -r /usr/local/subversion

Strictly speaking, both of the option flags are optional, but they are commonly used. The -d tag sets svnserve running as a background daemon. Under normal circumstances, you still need to keep the console window running for the server to stay up. The -r switch sets the root directory for client Subversion commands. In other words, all client URLs are resolved relative to this directory. Because this command sets up /usr/local/subversion as the Subversion root directory, users would access the Soups OnLine repository as:

svn://soupsonline

rather than

svn://usr/local/subversion/soupsonline

You can change the default host and port by using the options --listen-host and --listen-port. The default port is 3690. The -t and -i options prepare svnserve to be used over either an SSH tunnel (-t) or as a Unix inetd daemon (-i). These flags do not cause svnserve to be run those ways, but rather, they prepare svnserve to use stdin and stdout and to accept traffic as it comes in. See the Subversion documentation for more information about using inetd and SSH tunneling, or, for Windows users, running as a Windows service.

You can set up simple authentication for the svnserve server by modifying the conf/svnserv.conf file created in the repository (in other words, in /usr/local/subversion/soupsonline). Within that file are two commented-out options that are of interest: password-db and realm. The password-db option is the name of a file that contains the user information for this repository — typically that file is also placed in the conf directory. The realm option is an arbitrary label for the repository — it doesn't matter what it is, but it should be unique unless you have two repositories sharing a user file.

Two other options specify what different types of uses can do. The anon-access option specifies what an anonymous user can do. Valid values are read, write, and none (write access is assumed to include read access). The auth-access option specifies access for authorized users. The default is read for anonymous users, and write for authorized users. See the Subversion documentation if your access control needs are more complex than this.

The specified password file has the following simple format:

[users]
nrappin = bananamuffin
rlithgow = concrete
zpaleozogt = zot

It's just the user names and their clear text passwords.

That should be enough to get you started running Subversion for a team of developers. Now let's look at how Subversion manages the Rails ecosystem.