SVN的网络访问有四种常用协议。
svn://repos
svn+ssh://repos
https://repos
http://repos
维基百科页面并未详细说明四种不同协议的差异。我一直更喜欢svn://，因为它最容易设置，但有什么不同，哪一个更“好”？
答案 0 :(得分：54)
http://有严重的开销，尤其是在处理数千个小文件时。我使用svn作为一个拥有大约50,000个图标的网站，所有这些都保存在SVN中。使用HTTP，大约需要20分钟才能结账。切换到svn://后，花了不到一分钟。这是因为对于HTTP，每个文件都有一个新的HTTP请求。
http://具有以下巨大优势：它通常通过防火墙。例如，现在我切换到svn://我因为他们的防火墙而无法再从我的大学访问我的存储库。
关于使用SSL / TLS与否之间的区别，很明显：数据是加密的;但是设置起来比较困难。
答案 1 :(得分：20)
svn+ssh是在SSH隧道内运行的svn协议。客户端使用SSH登录远程服务器，并在该隧道中远程运行svn命令。在我看来，svn+ssh是在远程系统上使用subversion存储库的最简单方法，因为假设您已经运行了SSH服务器，那么在该系统上没有任何服务器可以启动。
此外，svn+ssh受益于SSH的加密保护。不要在不受信任的网络上使用原始svn协议。
svn+ssh的主要问题是它需要远程计算机上的shell访问权限。如果没有让他访问整个shell帐户，就很难向某人提供对存储库的访问权限。为此，您需要一种基于HTTP的方法，即http或https（最好是https，因为加密和身份验证层）。这些方法配置起来比较复杂（需要HTTP / HTTPS服务器，例如Apache），但允许存储库管理员仔细，精确地控制存储库访问权限。
答案 2 :(得分：5)
https://和svn+ssh://已加密，因此更安全地传输安全数据（例如您的SVN密码。
如果它与Git类似，svn+ssh://将比https://更快，svn://将比http://更快。
答案 3 :(得分：4)
此外，如果您使用http：//（Apache + SVN），那么您可以让您的用户使用Windows身份验证登录并添加mod_auth_sspi模块。
所以你的（windows）开发人员只需要记住一个用户/密码
答案 4 :(得分：4)
有人可能会说svn://或svn+ssh://在访问Subversion存储库时提供比普通HTTP或安全HTTPS更好的性能和速度，但现在情况并非如此。虽然svn://或svn+ssh://比HTTP（S）快，但差异并不像SVN 1.6或更早版本那么大。
HTTP（S）和最新的Subversion 1.7+客户端和服务器存在无主要性能问题。
使用Subversion 1.7 became much more performant and especially on high-latency network connections thanks to HTTPv2 进行HTTP（S）访问（不要与HTTP / 2混淆！）。 Subversion 1.8 switched from libneon to libserf for HTTP(S) access和libserf提供的效果优于libneon。
如果您认为某些问题与通过HTTP（S）工作的HTTP（S）或Subversion的性能有关，则应调查网络上是否存在使HTTP（S）变慢的任何服务。根本原因可能是防病毒，活动防火墙或代理。更不用说错误配置的网络设置了。并且不要忘记使用最新的Subversion客户端和服务器！
考虑到网络配置错误的例子，似乎存在一个非常常见的问题，它影响在无法访问Windows Update站点（http://ctldl.windowsupdate.com/）的断开连接的网络上工作的客户端计算机。这是一个影响各种系统服务的关键问题，但最终用户在通过HTTPS使用Subversion客户端时会注意到并报告它。问题看起来与性能有关，但事实并非如此。请阅读此StackOverflow线程以获取更多信息：https://stackoverflow.com/a/38499619/761095。
答案 5 :(得分：3)
http和https由Web服务器模块处理，用于Subversion支持，因此您可以使用基于HTTP的身份验证（通过.htaccess配置）来限制对存储库的访问。）