【发布时间】：2010-01-26 16:48:34
【问题描述】：
SVN的网络访问常用的协议有四种。
svn://repos
svn+ssh://repos
https://repos
http://repos
Wikipedia 页面没有过多说明四种不同协议的差异。我一直首选svn://，因为它是最容易设置的，但有什么区别，哪个“更好”？
【问题讨论】：
【发布时间】：2010-01-26 16:48:34
【问题描述】：
http:// 具有严重 开销，尤其是在处理数千个小文件时。我将 svn 用于一个有大约 50,000 个图标的网站，所有图标都保存在 SVN 中。使用 HTTP，结帐大约需要 20 分钟。切换到svn:// 后，只用了不到一分钟。这是因为对于 HTTP，每个文件都有一个新的 HTTP 请求。
http:// 但是有以下很大的优势：它通常可以通过防火墙。例如，现在我切换到svn://，由于他们的防火墙，我无法再从我的大学访问我的存储库。
关于是否使用 SSL/TLS 的区别，很明显：数据是加密的；但是设置起来比较困难。
【讨论】：
-
http(s):// 的另一个优点是符合 WebDAV 标准。这意味着您可以将此类存储库安装在例如explorer 或其他 WebDAV 客户端。见svnbook.red-bean.com/nightly/en/svn.webdav.html
-
Svn 从 v1.7 开始远离 WebDAV 标准，因为涉及的巨大开销和缺乏 WebDAV 客户端。
-
投了反对票，因为这个答案不再实际。 SVN 1.7 及更高版本大大提高了 HTTP(S) 的使用率，
svnserve的速度与 Apache 上的 HTTP(S) 之间的差异并不大。
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），但允许存储库管理员仔细和精确地控制存储库访问权限。
【讨论】：
-
有了svn+ssh，很容易限制对svn的访问。
-
@JohanBoulé，请解释一下。
-
@DwayneTowell 我认为这通常是“简单地”管理运行 SSH 服务器的系统上的用户的问题。
https:// 和 svn+ssh:// 已加密，因此传输安全数据（例如您的 SVN 密码）更安全。
如果它类似于 Git，svn+ssh:// 将比 https:// 快，svn:// 将比 http:// 快。
【讨论】：
-
我实际上对 svn+ssh 并不是很了解。服务器需要什么样的支持？您必须有一个在服务器上有外壳的 ssh 帐户吗？没有匿名访问？
-
SVN+SSH 与 svn:// 基本相同，只是你是通过 SSH 隧道进行的。如果匿名访问对您很重要，这不是您想要追求的选择。
-
@earlz：您需要某种具有对存储库的文件系统访问权限的帐户，以及运行
svn（或者可能是其他一些二进制文件？）的权限。 -
@Eric：如果你愿意，你可以在启用 SSH 的情况下进行匿名访问（不是你应该这样做，也不是说有意义）
-
@Andreas：确实如此。我有一个隐含的假设，即人们打算基于什么是明智的设计安全协议，所以警告并没有浮现在脑海中。 :) 也就是说，如果公共、匿名、端到端安全流量是您使用颠覆存储库的目标，那么 HTTPS 将是明智的选择。
有人可能会说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。
【讨论】：
-
AFAIK 一些操作，如果不是全部的话，通过 https 比 svn+ssh 更快。
此外，如果您使用 http:// (Apache + SVN)，那么您可以通过添加 mod_auth_sspi 模块让您的用户使用 Windows 身份验证登录。
因此您的（Windows）开发人员只需记住一个用户/密码
【讨论】：
http 和 https 由 Web 服务器模块处理以支持 Subversion，因此您可以使用基于 HTTP 的身份验证（通过 .htaccess 配置）来限制对您的存储库的访问。
【讨论】：
-
好吧，您也可以使用 svnserve 进行身份验证。只是方式稍有不同。
-
是的，如果同一个开发者组有 100 个存储库，则需要在任何存储库之间传输配置文件。这样，您只能拥有一个允许他们访问的文件，并且其中的每一项更改都将控制对任何存储库的访问
-
你可以使用 svnserve + symlinks 获得同样的效果。此外，为同一个开发人员组创建多个存储库是没有意义的，并且不鼓励使用官方 svn 书籍。
-
示例：我有一个开发团队（7 人），负责多个客户项目。他们必须有权访问位于一台计算机上的存储库和“完整实时预览”。没有其他人应该有权访问实时预览。我可以配置我的 apache，只有他们可以访问多个文件夹和 url，当其中一名开发人员离开团队时 - 我只需要在一个地方更改访问权限。
-
通过 HTTP，使用 Windows Active Directory 进行身份验证要容易得多。这在 Windows 环境中很方便。