那你应该用什么服务器？什么最好？
显然，对这个问题没有正确的答案，每个团队都有不同的需要，不同的服务器都有各自的代价。Subversion项目没有更加认可哪种服务，或认为哪个服务更加“正式”一点。
下面是你选择或者不选择某一个部署方式的原因。
设置快速简单。
网络协议是有状态的，比WebDAV快很多。
不需要在服务器创建系统帐号。
不会在网络传输密码。
By default, only one authentication method is available, the network protocol is not encrypted, and the server stores clear text passwords. (All these things can be changed by configuring SASL, but it's a bit more work to do.)
没有任何类型的日志，甚至是错误。
No built-in web browsing. (You'd have to install a separate web server and some CGI software to add this.)
网络协议是有状态的，比WebDAV快很多。
You can take advantage of existing SSH accounts and user infrastructure.
所有网络传输是加密的。
只有一个认证方法选择。
没有任何类型的日志，甚至是错误。
Requires users to be in same system group, or use a shared SSH key.
如果使用不正确，会导致文件许可问题。
允许Subversion使用大量已经集成到Apache的用户认证系统。
不需要在服务器创建系统帐号。
完全的Apache日志。
网络传输可以通过SSL加密。
HTTP(S) 通常可以穿越公司防火墙。
通过web浏览器访问内置的版本库浏览。
Repository can be mounted as a network drive for transparent version control (see “自动版本化”一节).
Noticeably slower than svnserve, because HTTP is a stateless protocol and requires more network turnarounds.
初始设置可能复杂
通常，本书的作者推荐希望尝试开始使用Subversion的小团队使用svnserve；这是设置最简单，维护最少的方法，而当你的需求改变时，你可以转换到复杂的部署方式。
下面是一些常见的建议和小技巧，基于多年对用户的支持：
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 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 or svnserve with SASL encryption 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 “支持多种版本库访问方法”一节). 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 it can entail all the same
problems if the administrator isn't careful.