那你应该用什么服务器？什么最好？
显然，对这个问题没有正确的答案，每个团队都有不同的需要，不同的服务器都有各自的代价。Subversion项目没有更加认可哪种服务，或认为哪个服务更加“正式”一点。
下面是你选择或者不选择某一个部署方式的原因。
设置快速简单。
网络协议是有状态的，比WebDAV快很多。
不需要在服务器创建系统帐号。
不会在网络传输密码。
By default, only one authentication method is available, the network protocol is not encrypted, and the server stores cleartext 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快很多。
你可以利用现有的ssh帐号和用户基础。
所有网络传输是加密的。
只有一个认证方法选择。
没有任何类型的日志，甚至是错误。
需要用户在同一个系统组，使用共享ssh密钥。
如果使用不正确，会导致文件许可问题。
允许Subversion使用大量已经集成到Apache的用户认证系统。
不需要在服务器创建系统帐号。
完全的Apache日志。
网络传输可以通过SSL加密。
HTTP(S) 通常可以穿越公司防火墙。
通过web浏览器访问内置的版本库浏览。
版本库可以作为网络驱动器加载，实现透明的版本控制，见“自动版本”一节。
比svnserve慢很多，因为HTTP是无状态的协议，需要更多的传递。
初始设置可能复杂
通常，本书的作者推荐希望尝试开始使用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.
如果你已经决定使用Apache或svnserve，应该单独创建一个运行服务器进程的svn用户，也需要确定版本库目录属于svn用户。从安全的角度，这样很好的利用了操作系统的文件系统许可保护了版本库数据，只有Subversion服务进程可以修改其内容。
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.
不要被简单的让所有用户使用file://的URL访问版本库的方案诱惑，即使，版本库版本库已经对网络共享的所有用户可见，这也不是一个好方案。这样删除了用户和版本库之间的所有保护层：用户可能会偶然（或有意的）毁坏版本库数据库，这样也很难在检查或升级时将版本库脱机，而且这样会造成曾混乱的文件许可问题（见“支持多种版本库访问方法”一节。），注意那就是我们警告使用svn+ssh://的原因—从安全角度讲，这样与作为本地用户访问file://是一样的，如果管理员不小心，会造成同样的问题。