svn - 选择 Subversion 服务器

Question

在为我的版本控制需求选择了Apache Subversion （为我的主要 Subversion 客户端选择了AnkhSVN / TortoiseSVN ）之后。现在我正在尝试选择 SVN 服务器来提供对 SVN 存储库的远程访问。我看过其中的几个：

• CollabNet 颠覆边缘
• VisualSVN 服务器

我已将每个安装在 VM 中以试用它们，但还没有找到足以区分它们中的大多数以选择任何特定的。现在我有几件事需要决定。

1. 协议
2. 小贩
3. SSL

1.我看过HTTP比SVN协议慢很多。虽然我的项目通常不会太大（实际上只有初始导入是耗时的部分），但我确实希望获得 SVN 的性能优势，并避免我的 HTTP 日志被 SVN 条目淹没（我有截至目前还无法分离成单独的 LOG 文件）。

不过，我确实喜欢使用 Apache 模块或 VisualSVN 提供的 Web 界面。我真的不需要将我的东西提供给其他人（甚至我自己远离我的系统），所以它并不重要，但它确实允许可扩展性。

2.选择协议后（假设我必须选择）；我需要帮助决定使用哪个供应商。我最初使用的是 Tigris 发行版中的 Apache 模块。我已经删除了它（好吧，只是禁用了它），并且目前正在使用 VisualSVN（它是 HTTP，因此速度很慢）。我见过人们支持 Sharp 和 Silk，但它们似乎更小，独立发行版。
另一方面，Collabnet 似乎比我需要的更复杂。基本上，除非我能说服其中之一，否则我主要只是想在官方的 Tigris 和 VisualSVN 之间进行选择。

3. 我也尝试过使用 SSL，但没有取得多大成功（我买不起真正的 CA，所以我在 VisualSVN 中使用自签名证书）。我很乐意使用 SVN+SSH/HTTPS，但如果我在自己的系统上使用它，那就没有必要了，如果我在外部使用它，那么我的自签名证书将无济于事。

我想我什至可以使用本地存储库；我认为这将是最快的。但是，如果我扩展，我更喜欢更正式的解决方案。（我考虑过只使用 TortiseSVN 客户端在本地完成服务器的工作。）

所以总而言之，我需要一些关于使用哪个服务器（s？）的建议。如果我可以让 VisualSVN 提供一个供 Web 使用的 HTTP 接口，而且还可以在客户端使用的 SVN 协议上提供服务，最好在每个客户端上使用 SSL 选项，那就太好了。那可能吗？工作量会不会太大（我真的很想重新开始我的项目，而不是所有这些元工作）。

非常感谢。

编辑

我想我应该提供一些关于我的情况的信息来澄清事情。

• （目前）单系统，（旧版 P4，Windows，1GB SDRAM）
• （目前）单开发者（我）
• （目前）相对较小的项目（<2MB）
• 无数项目（>100 个单独的应用程序、游戏、库、网站等）
• 需要外部（特别是我自己的库以及第 3 方标头、Boost 等）
• ? 嗯，还有什么……</li>

Answer 1

编辑：在这里阅读其他答案后，我认为我应该提到一件事。如果您尝试使用一台服务器，则您要求它提供服务的存储库与您要求另一种类型的服务器提供服务的存储库没有什么不同。

换句话说，如果您决定现在尝试一个服务器，您可以稍后切换到另一种类型的服务器，而不会丢失您的存储库。当然，工作副本以及您在项目中所做的任何绝对外部引用都必须更改，但您可以保留存储库的历史和所有内容。

---

我在VisualSVN Server发布时安装了它，并且对它非常满意，有一段时间。

然而，速度问题让我切换到作为 Subversion 命令行包的一部分提供的主 svnserve 服务器。

主要问题是我正在使用 .NET，并且我选择将几个外部 Subversion 引用添加到我的项目中。

首先，最重要的是，我在类库中创建的每个项目都由我的密钥签名。其次，添加了外部第三方库，如SQLite和NUnit，作为外部引用。

每个项目都有自己的外部参考。我这样做是为了能够创建一个新的应用程序项目，然后对我需要的类库部分进行新的外部引用，并使这些引用完整。如果我在 .NET 中的类库解决方案有一个签名密钥文件的外部引用，并且该文件不能作为任何单个项目的一部分使用，而是位于所有项目之外的磁盘上，但位于我的解决方案的本地，那将没有工作。

因此，我的类库解决方案包含大约 15-20 个项目，每个项目至少有一个对签名密钥的外部引用，我所有的数据项目都有对 SQLite 库的外部引用，而单元测试库有 4-5 个外部引用。

最终结果是解决方案级别的单个更新，即使我已经拥有所有最新的文件、目录和所有内容，也需要大约 2 分钟才能完成。每一个外部参考都需要 10 到 20 秒才能完成，只是为了验证我是否有所需的修订。

当我切换到 svnserve 时，这 2 分钟减少到大约 3 秒。请注意，这是本地流量，因此当然这在互联网上会有所不同。问题是，那 2 分钟也是本地交通。

因此，虽然我非常喜欢 VisualSVN Server 为我提供的界面，包括轻松设置访问权限和用户的能力，但与 svnserve 和本机 Subversion 协议相比，Apache 服务器模块提供给我的速度绝对是可怕的.

请注意，从那以后我安装了一个单独的 Apache 服务器，浏览了许多配置文件，并使用 Apache 设置了 Subversion，而不是通过 VisualSVN 服务器，只是为了确保它不仅仅是 VisualSVN，我已经确认速度我观察到的不是 VisualSVN 团队的工作。似乎 HTTP 协议或 Apache 模块并没有那么快。

如果可能的话，我的建议是使用主 svnserve 服务器。可能需要一些工作来了解授权等配置文件，但单独的刺激因素（即根本没有对速度的刺激）很可能超过这一点。

Answer 2

重新访问速度：我看到https:需要硬件更新的 Apache SVN 服务器。我似乎记得主要是内存不足，这减慢了争夺机器资源的众多 Apache 进程。但那是 20 名开发人员在一个项目上协作，该项目有一个 20GB 的签出树（其中有很多二进制文件，经常发生变化）。对装备中等的服务器的更新解决了这个问题。

此外，在那个项目中，我不得不了解到 Linux 下 ext3 FS 上的 SVN 至少比 Windows 下的 NTFS 上快一个数量级。请注意：在 Windows 上运行的虚拟机中的 Linux 与运行虚拟机的 Windows 机器竞争的更新时间是其十分之一。（我们一直想尝试适用于 Windows 的 OS ext3 驱动程序，看看这是否会使 Windows 上的 SVN 比其本机 FS 更快。但是，在我们开始尝试之前我就离开了这个项目。）

无论如何，这不像你决定的东西是永恒的。您可以尝试一件事，在实际项目中对其进行彻底测试，然后再切换到不同的服务器和协议。（甚至还有一个 SVN 命令来切换签出树的 URL 。您可以使用它来切换协议，而无需重新签出所有内容。）

以下是我在决定协议时会考虑的内容：如果您有一个工作的 AD 或 LDAP 基础架构，您想利用它来登录 SVN，请尝试http/ https:protocol 选项之一。如果你没有这个，你也不需要它，你用SVN自己的方式登录也没问题，为什么不使用svn:协议提供的速度呢？

我从未见过人们使用 WebDAV 访问的 SVN 存储库。IME 他们总是希望在访问每个 Web 时拥有历史记录（WebDAV 不提供此功能，AFAIK），因此他们使用了 SVN 的 Web 前端之一。我从未检查过，但我只是假设ViewVC之类的东西不关心他们使用哪种协议来访问存储库。

至于你想使用哪个发行版——我认为这主要取决于个人喜好，因为下面的代码无论如何都是一样的。我更喜欢无需注册的下载和明确针对我想要安装它们的平台的发行版。但这可能只是我。

但是，如果您的存储库可以从 Internet 访问，您可能需要考虑一个很难的事实：当 SVN 项目发布新的 dot 版本时，它过去多久采用不同的发行版来赶上。由于这些可能是安全修复程序，您可能更喜欢通常更快地提供修复程序的那些。

Answer 3

我们使用由在 CentOS 5.3 下运行的 Apache 提供的 HTTP 从 XEN 虚拟机内部提供我们的 SVN 存储库。

我观察到对大文件进行提交或签出时，会以接近网络的速度传输该文件。在签出或提交大量小文件时，HTTP 请求的开销要明显得多。

与编译代码的时间尺度相比，SubVersion 并不被视为公司内部的瓶颈。

（这是我与 10 名开发人员组成的团队的经验）

Answer 4

我在家里和工作中使用 CollabNet。很好 - 没有对性能的抱怨。