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 that either the repository's contents aren't sensitive (e.g. it contains only open-source code), or that you go the extra mile in configuring SASL to encrypt network communications.
If you need to integrate with existing legacy identity systems (LDAP, Active Directory, NTLM, X.509, etc.), then you must use either the Apache-based server or svnserve configured with SASL. If you absolutely need server-side logs of either server errors or client activities, then an Apache-based server is your only option.
If you've decided to use either Apache or stock
svnserve, create a
svn user on your system and run
the server process as that user. Be sure to make the
repository directory wholly owned by
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
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 or svnserve with SASL encryption instead.
Do not be seduced by the simple
idea of having all of your users access a repository
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
URLs—from a security standpoint, it's effectively
the same as local users accessing
file://, and can entail all the
same problems if the administrator isn't careful.