Obviously, there's no right answer to that question. Every
team has different needs, and the different servers all
represent different sets of tradeoffs. The Subversion project
itself doesn't endorse one server or another, or consider either
server more “official” than another.
Here are some reasons why you might choose one deployment
over another, as well as reasons you
might not choose one.
The svnserve Server
Why you might want to use it:
Quick and easy to set
up.
Network protocol is stateful and
noticeably faster than WebDAV.
No need to create system accounts on
server.
Password is not passed over the
network.
Why you might want to avoid it:
Network protocol is not
encrypted.
Only one choice of authentication
method.
Password is stored in the clear on the
server.
No logging of any kind, not even
errors.
svnserve over SSH
Why you might want to use it:
Network protocol is stateful and
noticeably faster than WebDAV.
You can take advantage of existing ssh
accounts and user infrastructure.
All network traffic is
encrypted.
Why you might want to avoid it:
Only one choice of authentication
method.
No logging of any kind, not even
errors.
Requires users to be in same system group, or
use a shared ssh key.
If used improperly, can lead to file permissions
problems.
The Apache HTTP Server
Why you might want to use it:
Allows Subversion to use any of the
numerous authentication systems already integrated
with Apache.
No need to create system accounts on
server.
Full Apache logging.
Network traffic can be encrypted via
SSL.
HTTP(S) can usually go through corporate
firewalls.
Noticeably slower than svnserve, because
HTTP is a stateless protocol and requires more
turnarounds.
Initial setup can be complex.
Recommendations
In general, the authors of this book recommend a vanilla
svnserve installation for small teams just
trying to get started with a Subversion server; it's the
simplest to set up, and has the fewest maintenance issues.
You can always switch to a more complex server
deployment as your needs change.
Here are some general recommendations and tips, based on
years of supporting users:
If you're trying to set up the simplest possible
server for your group, then a
vanilla svnserve installation is the
easiest, fastest route. Note, however, that your
repository data will be transmitted in the clear over the
network. If your deployment is entirely within your
company's LAN or VPN, this isn't an issue. If the
repository is exposed to the wide-open internet, then you
might want to make sure the repository's contents aren't
sensitive (e.g. it contains only open-source code.)
If you need to integrate with existing identity
systems (LDAP, Active Directory, NTLM, X.509, etc.), then
an Apache-based server is your only real option.
Similarly, if you absolutely need server-side logs of
either server errors or client activities, then an
Apache-based server is required.
If you've decided to use either Apache or stock
svnserve, create a
single svn user on your system and run
the server process as that user. Be sure to make the
repository directory wholly owned by
the svn user as well. From a security
point of view, this keeps the repository data nicely
siloed and protected by operating system filesystem
permissions, changeable by only the Subversion server
process itself.
If you have an existing infrastructure heavily based
on SSH accounts, and if your users already have system
accounts on your server machine, then it makes sense to
deploy an svnserve-over-ssh solution. Otherwise, we don't
widely recommend this option to the public. It's
generally considered safer to have your users access the
repository via (imaginary) accounts managed
by svnserve or Apache, rather than by
full-blown system accounts. If your deep desire for
encrypted communication still draws you to this option, we
recommend using Apache with SSL instead.
Do not be seduced by the simple
idea of having all of your users access a repository
directly via file:// URLs. Even if
the repository is readily available to everyone via
network share, this is a bad idea. It removes any layers
of protection between the users and the repository: users
can accidentally (or intentionally) corrupt the repository
database, it becomes hard to take the repository offline
for inspection or upgrade, and it can lead to a mess of
file-permissions problems (see
the section called “Supporting Multiple Repository Access Methods”.) Note
that this is also one of the reasons we warn against
accessing repositories via svn+ssh://
URLs–from a security standpoint, it's effectively
the same as local users accessing
via file://, and can entail all the
same problems if the administrator isn't careful.
