The easiest option is to run svnserve as a standalone “daemon” process. Use the -d option for this:

$ svnserve -d
$               # svnserve is now running, listening on port 3690

When running svnserve in daemon mode, you can use the --listen-port and --listen-host options to customize the exact port and hostname to “bind” to.

Once we successfully start svnserve as explained previously, it makes every repository on your system available to the network. A client needs to specify an absolute path in the repository URL. For example, if a repository is located at /var/svn/project1, a client would reach it via svn://host.example.com/var/svn/project1. To increase security, you can pass the -r option to svnserve, which restricts it to exporting only repositories below that path. For example:

$ svnserve -d -r /var/svn
...

Using the -r option effectively modifies the location that the program treats as the root of the remote filesystem space. Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:

$ svn checkout svn://host.example.com/project1
...

If you want inetd to launch the process, you need to pass the -i (--inetd) option. In the following example, we’ve shown the output from running svnserve -i at the command line, but note that this isn’t how you actually start the daemon; see the paragraphs following the example for details on how to configure inetd to start svnserve:

$ svnserve -i
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )

When invoked with the --inetd option, svnserve attempts to speak with a Subversion client via stdin and stdout using a custom protocol. This is the standard behavior for a program being run via inetd. The Internet Assigned Numbers Authority (IANA) has reserved port 3690 for the Subversion protocol, so on a Unix-like system you can add lines to /etc/services such as these (if they don’t already exist):

svn           3690/tcp   # Subversion
svn           3690/udp   # Subversion

If your system is using a classic Unix-like inetd daemon, you can add this line to /etc/inetd.conf:

svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i

Make sure “svnowner” is a user that has appropriate permissions to access your repositories. Now, when a client connection comes into your server on port 3690, inetd will spawn an svnserve process to service it. Of course, you may also want to add -r to the configuration line as well, to restrict which repositories are exported.

A third way to invoke svnserve is in tunnel mode, using the -t option. This mode assumes that a remote-service program such as rsh or ssh has successfully authenticated a user and is now invoking a private svnserve process as that user. (Note that you, the user, will rarely, if ever, have reason to invoke svnserve with the -t at the command line; instead, the SSH daemon does so for you.) The svnserve program behaves normally (communicating via stdin and stdout) and assumes that the traffic is being automatically redirected over some sort of tunnel back to the client. When svnserve is invoked by a tunnel agent like this, be sure that the authenticated user has full read and write access to the repository database files. It’s essentially the same as a local user accessing the repository via file:// URLs.

This option is described in much more detail later in this chapter in Tunneling over SSH.

If your Windows system is a descendant of Windows NT (2000, 2003, XP, or Vista), you can run svnserve as a standard Windows service. This is typically a much nicer experience than running it as a standalone daemon with the --daemon (-d) option. Using daemon mode requires launching a console, typing a command, and then leaving the console window running indefinitely. A Windows service, however, runs in the background, can start at boot time automatically, and can be started and stopped using the same consistent administration interface as other Windows services.

You’ll need to define the new service using the command-line tool SC.EXE. Much like the inetd configuration line, you must specify an exact invocation of svnserve for Windows to run at startup time:

C:> sc create svn
        binpath= "C:svninsvnserve.exe --service -r C:
epos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

This defines a new Windows service named “svn,” which executes a particular svnserve.exe command when started (in this case, rooted at C: epos). However, there are a number of caveats in the prior example.

First, notice that the svnserve.exe program must always be invoked with the --service option. Any other options to svnserve must then be specified on the same line, but you cannot add conflicting options such as --daemon (-d), --tunnel, or --inetd (-i). Options such as -r or --listen-port are fine, though. Second, be careful about spaces when invoking the SC.EXE command: the key= value patterns must have no spaces between key= and must have exactly one space before the value. Lastly, be careful about spaces in your command line to be invoked. If a directory name contains spaces (or other characters that need escaping), place the entire inner value of binpath in double quotes, by escaping them:

C:> sc create svn
        binpath= ""C:program filessvninsvnserve.exe" --service -r C:
epos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

Also note that the word binpath is misleading—its value is a command line, not the path to an executable. That’s why you need to surround it with quotes if it contains embedded spaces.

Once the service is defined, it can be stopped, started, or queried using standard GUI tools (the Services administrative control panel) or at the command line:

C:> net stop svn
C:> net start svn

The service can also be uninstalled (i.e., undefined) by deleting its definition: sc delete svn. Just be sure to stop the service first! The SC.EXE program has many other subcommands and options; run sc /? to learn more about it.