There are a few different ways to invoke the
svnserve
program. If invoked with no
options, you'll see nothing but a help message. However, if
you're planning to have
inetd
launch the
process, then you can pass the -i
(--inetd) option:
$ 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 IANA has reserved port 3690
for the Subversion protocol, so on a Unix-like system you can
add lines to /etc/services like these (if
they don't already exist):
svn 3690/tcp # Subversion
svn 3690/udp # Subversion
And 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 which 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.
On a Windows system, third-party tools exist to run
svnserve
as a service. Look on Subversion's
website for a list of these tools.
A second 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.
There's still a third way to invoke
svnserve
, and that's in “tunnel
mode”, with 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
. 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. (See
Servers and Permissions: A Word of Warning.) It's essentially the same as
a local user accessing the repository via
file:/// URLs.
Once the
svnserve
program is running,
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
/usr/local/repositories/project1, then a
client would reach it via svn://host.example.com/usr/local/repositories/project1
. To increase security, you can pass the
-r option to
svnserve
,
which restricts it to exporting only repositories below that
path:
$ svnserve -d -r /usr/local/repositories
…
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
…
