Subversion有多种服务器类型：
哪个最适合小型Linux系统（一到两个用户）？
答案 0 :(得分：13)
http：
<强> HTTPS：
<强>的svn：
<强> SVN + SSH
答案 1 :(得分：4)
其中1个选项绝对是“最差”的选项：文件访问权限。不要使用它，而是使用一种基于服务器的方法。
但是，是否使用HTTP或Svnserve完全是一个偏好问题。事实上，你可以同时使用它们，repo上的写锁定确保你不会破坏任何东西，如果你使用它然后使用另一个。
我的偏好只是使用apache - http更多防火墙和互联网友好，它也更容易挂钩到ldap或其他身份验证机制，你也得到像webdav这样的功能。性能可能低于svnserve，但不是特别明显（通过网络传输数据占任何性能问题的大部分）
如果您需要文件传输的安全性，则可以选择svnserve + ssh或https上的apache。
答案 2 :(得分：3)
结帐FLOSS Weekly Episode 28。 Greg Stein是SVN WebDAV协议的发明者之一，并讨论了权衡。我的看法是SVN：更快，但http / webdav实现几乎适用于所有目的。
答案 3 :(得分：2)
我一直使用XInetD和HTTP。 HTTP也有WebDAV，所以如果我愿意，我可以在线浏览源代码（如果你想要加密和暗网类型的东西，你可以要求VPN）。
这实际上取决于你所处的限制（如果有的话）。
它只能在局域网上吗？你需要在局域网外访问吗？ 如果是这样，你会有VPN吗？ 你有静态IP地址，是否允许转发端口？
如果您没有受到任何限制，我建议您使用xinetd（如果您安装了xientd，守护进程，如果您没有），然后（如果您需要远程访问）使用基于http的服务器（如果您需要）远程访问（如果您不希望发送纯文本un / pw，也可以使用HTTPS加密。）
大多数其他选择都是更多的努力而且收益更少。
这是一个SVN回购 - 如果你不喜欢它，你可以随身携带行李并换货。
答案 4 :(得分：2)
为了便于管理和安全，我们将svn + ssh用于需要提交访问权限的任何内容。我们已经为一些开源代码的匿名（只读）访问设置了基于HTTP的访问，而且速度要快得多; svn + ssh的问题在于它必须为每个操作启动一个ssh连接和一个全新的svnserve，这可能会在一段时间后变得非常慢。
所以，我建议：
答案 5 :(得分：1)
我喜欢sliksvn在Windows中作为服务运行，2分钟即可设置然后忘掉它 它还附带了客户端工具，但也下载了龟。
答案 6 :(得分：1)
如果您打算仅在本地计算机上使用服务器并了解unix权限，则使用file：// urls将快速，简单且安全。同样，如果您了解unix权限和ssh并需要远程访问它，ssh将会很好用。虽然我看到其他人提到它“最糟糕”，但我很确定这只是因为需要了解unix权限。
如果您不喜欢或不了解unix权限，则需要使用svnserve或http。我可能会选择在xinetd中亲自运行它。
最后，如果您遇到防火墙或代理问题，则可能需要考虑使用http。这要复杂得多，而且我认为你不会看到好处，所以我会把它放在你的名单上。
答案 7 :(得分：1)
我建议使用http选项，因为我目前正在使用svn+ssh，它似乎是可用协议的红头发的继子：第三方工具支持对{ {1}}而不是svn+ssh。
答案 8 :(得分：1)
我一直负责为我的开发团队管理svnserve和Apache + SVN，我更喜欢基于http的解决方案，因为它具有灵活性。我几乎不知道系统管理，毕竟我是一个软件人员，我喜欢能够将身份验证和授权交给Apache。
这两个队的队员大约10到15人，两种方法同样运作良好。如果您计划将来进行任何扩展，可以考虑使用基于http的解决方案。它与svnserve一样容易配置，如果您不打算将服务器暴露给Internet，那么您也不必过于担心保护和管理Apache。
作为SVN的用户，我更喜欢与Apache进行基于http的集成。我喜欢能够使用我的网络浏览器浏览存储库。
答案 9 :(得分：0)
我很好奇为什么不FSFS？重要信息 - 我正在管理Windows系统。
我用SVN完成了很多项目，几乎所有项目都是从FSFS运行的。最大的存储库大约为70GB（极端），最大的存储库大约为700.
我们从未遇到任何问题，即使我们在Windows，NetApp和许多其他存储系统上托管它。大多数时候，当我问为什么不使用FSFS时，问题只是人们根本不相信它。
优点：
缺点：
马丁