Subversion Version Control. Using The Subversion Version Control System in Development Projects

3.5. Configuring SVN to Use svnserve

If, for whatever reason, Apache is not a practical solution for allowing remote access to a Subversion repository, there is also a standalone server, which you can use in place of Apache. This Subversion server, svnserve, allows a client to access the repository via a custom Subversion protocol, instead of the extended WebDAV protocol that the client uses when talking to the Apache server. The server can run by itself as a persistent process that listens on a dedicated port, or as an on-demand process that is either started over a tunneled SSH/RSH session or by an inetd server.

The svnserve server is contacted from the Subversion client using a URL that begins with svn:// or svn+ssh://, instead of the http:// prefix used for WebDAV. Like WebDAV, the body of the URL will then consist of the server being contacted, followed by the path to the repository. If the svnserve process was invoked without a repository root specified, the path that the client gives must be an absolute pathname. For example, if the repository is located in /srv/svn/repos, you would need to use the URL svn://example.com/srv/svn/repos.

To increase both security and ease of use, you can give a repository root when invoking svnserve using the argument --root PATH. If a root is given, repository URL paths will be relative to that root, and unable to access anything outside of that directory. So, --root/srv/svn would make the preceding URL svn://example.com/repos.

3.5.1. Running as a Daemon

The easiest way to run svnserve is as a standalone daemon process, which runs in the background and listens on a port for requests from Subversion clients. You can run the server this way from the command line, by running the following.

$ svnserve --daemon --root=/srv/subversion/

The --daemon parameter tells svnserve that it should disconnect from the shell and go into the background after it starts, and the --root parameter, of course, gives it a root for repository URLs. In order for the server to access your repository, you need to make sure svnserve runs as a user who has filesystem read/write permission for your repository.

By default, svnserve listens on port 3690, and responds to requests directed at all hostnames and IP addresses bound to the machine the server is running on. If you would rather have svnserve listen on a different port, you can give it a port with --listen-port=PORT, where PORT is the port to listen on. Additionally, if you want the server to bind to a particular hostname, you can give it the hostname with --listen-host=HOSTNAME.

Instead of explicitly invoking the svnserve daemon process from the command line every time you want to start it, you can also set up the server to be started as a service when your machine boots, or enters certain runlevels. Every OS and distribution handles startup services a little differently, so the specifics of setting up such a service is beyond the scope of this book, but documentation on how to set up such a service is usually readily available. If you installed a binary package, using your distribution's package management system, you may find that the hard work of setting up a service to start svnserve has already been done, and all you need is to configure it to be started.

3.5.2. Running with inetd

An alternate method for running svnserve is to use a UNIX inetd server to start svnserve on demand, as it receives requests from a client. In order to allow you to run svnserve this way, it has a special mode for invocation from inetd, which is specified with the command-line parameter, --inetd. When it is started this way, svnserve handles all of its input and output through stdin and stdout, which is how inetd expects to talk to services. As with running svnserve in daemon mode, you need to make sure that svnserve is run by a user who has filesystem read/write permission for any repositories the server will access.

Setting up svnserve to use inetd requires you to configure the service to react in response to an SVN request on the Subversion port (which is 3690, by default). Start by telling inetd what to do, which involves putting an entry in the inetd configuration file(s), in /etc. The exact configuration file to edit will depend somewhat on your particular inetd server and operating system distribution, but most systems use one of two methods.

Modern distributions are moving toward using the much more secure inetd implementation, xinetd. If your system uses it, you will need to add a file to /etc/xinetd/, named svn. In this file, you will need to add something like the following lines.

service svn { socket_type = stream protocol = tcp user = svnuser wait = no server = /usr/bin/svnserve server_args = --inetd --root=/srv/svn }

This tells xinetd that it should expect a stream of data, over TCP, and should then launch the svnserve program, with the server_args arguments, and should run it as svnuser (which needs to have read/write access to the repository).

Then, for xinetd to know when to invoke the service, you need to add the line

svn 3690/tcp

to your /etc/services file.

If you have a more traditional inetd server installed, the setup process is similar; instead of adding /etc/xinetd/svn, you add the following line to /etc/inetd.conf:

svn stream tcp nowait svnuser /usr/bin/svnserve svnserve --inetd --root =/srv/svn

The /etc/services file should be set up the same.

3.5.3. Tunneling over SSH

You can also use svnserve by tunneling over SSH. To allow this, you need to make sure that every user accessing the repository has an account on the server that allows him to connect via SSH. You will also need to make sure that he has permission to modify the Subversion repository on the server's filesystem; svnserve will be invoked locally on the server with the --tunnel option when the user connects. Then, all he needs to do is feed a URL with an svn+ssh:// schema to his SVN client and Subversion will handle the rest, like in the following checkout:

$ svn checkout svn+ssh://svn.example.com/repos