选择一个Subversion服务器

Question

选择Apache Subversion我的版本控制需求（和AnkhSVN/TortoiseSVN我主要的Subversion客户端）之后。现在我试图选择SVN服务器来提供对SVN存储库的远程访问。我已经看过他们夫妇：

• CollabNet Subversion Edge
• VisualSVN Server

我已经安装在每一个虚拟机尝试一下，但还没有找到足够的区分大多足以挑选具体的。现在我有几件事需要决定。

1. 协议
2. 厂商
3. SSL

1.我已阅读，HTTP比SVN协议得多慢。虽然我的项目通常不是太大（实际上只是最初的导入是耗时的部分），但我确实希望获得SVN的性能优势，以及避免我的HTTP日志充斥着SVN条目（其中I至今尚未能隔离成单独的LOG文件）。

但我喜欢使用Apache模块或VisualSVN提供的网页界面。我并不需要向其他人（甚至是我自己的系统）提供我的东西，所以它不是关键，但它肯定允许可扩展性。

2.选择协议后（假设我有选择）;我需要帮助决定使用哪个供应商。我最初使用了Tigris发行版中的Apache模块。我已经删除了（嗯，只是禁用它），我目前正在使用VisualSVN（这是HTTP，因此很慢）。我看到人们赞同夏普和丝绸，但他们似乎更小，独立发行。
另一方面，Collabnet似乎比我需要的更精细。基本上，除非我能说服其中一个人，否则我主要是试图在官方的Tigris和VisualSVN之间做出选择。

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

我想我甚至可以使用本地存储库;我会认为这将是最快的。但是，如果我扩展，我更喜欢更正式的解决方案。 （我认为只使用TortiseSVN客户做本地服务器的工作。）

因此，在总结，我需要哪些服务器上的一些建议（小号？）来使用。如果我能让VisualSVN提供一个供Web使用的HTTP接口，而且还可以在客户端使用SVN协议，最好是在每个客户端上都使用SSL，那么最好的办法是。那可能吗？工作是否太多（我真的想回到我的项目上而不是所有这些元工作上）。

非常感谢。

编辑

我想我应该给我的情况下，提供一些信息，以澄清事情。

• （目前）单系统，（较老的P4，Windows中，1GB SDRAM）
• （目前）单个开发者（我）
• （目前）相对较小的项目（< 2MB）
• 无数项目（> 100个人应用程序，游戏，图书馆，网站等）
• 需要外部（特别是我自己的库以及第三方标题，Boost等）
• ？嗯，还有什么...

Answer 1

编辑：这里阅读其他的答案后，有一两件事，我想我应该不在话下。如果您尝试使用一台服务器，则您要求其提供服务的存储库与您要求提供另一种服务器类型的存储库没有区别。

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

---

我安装VisualSVN Server，当它宣布，并且是与它很高兴，一会。

但是，速度问题让我转向作为Subversion命令行包一部分提供的主要svnserve服务器。

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

首先，我的课程库中的每个项目都由我的密钥签名。其次，添加外部第三方库，如SQLite和NUnit作为外部参考。

每个项目都有自己的外部参考。我这样做是为了能够创建一个新的应用程序项目，然后为我需要的我的类库的某些部分创建新的外部引用，并使这些引用完整。如果我在.NET中的类库解决方案有一个用于签名密钥文件的外部引用，并且该文件不作为任何单个项目的一部分提供，但位于所有项目之外的磁盘上，但位于我的解决方案的本地磁盘上没有工作。因此，我的类库解决方案包含15-20个项目，每个项目至少有一个外部引用到签名密钥，我所有的数据项目都有外部引用到SQLite库，单元测试库有4-5个外部参考。

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

当我切换到svnserve时，那2分钟减少到3秒左右。这是当地的交通头脑，所以当然这在互联网上会有所不同。问题是，那2分钟也是本地流量。

所以，虽然我绝对喜欢的界面VisualSVN服务器为我提供了，包括能够容易设置访问权限的用户，即Apache服务器模块提供了我的速度是什么svnserve的比较绝对可怕和本地的Subversion协议。

请注意，从那时起，我已经安装了一个单独的Apache服务器，通过大量配置文件进行扫描，并通过Apache设置Subversion而不是通过VisualSVN服务器，只是为了确保它不仅仅是VisualSVN，而且我证实我观察到的速度不是VisualSVN团队的工作。看来HTTP协议或Apache模块并不那么快。

我的建议是在可能的情况下使用主svnserve服务器。可能需要一些工作才能了解配置文件的授权和类似情况，但单独的刺激因素（即对速度没有任何刺激）将超过这个可能性。

Answer 2

我在家中和工作中使用CollabNet。这很好 - 没有表现抱怨。

Answer 3

重新访问速度：我看到一个Apache https:需要硬件更新的SVN服务器。我似乎记得它主要是缺乏内存，这减慢了许多争夺机器资源的Apache进程。但那是20个开发者在一个20GB的签出树上进行项目合作（大量的二进制文件，经常改变）。而对装备适中的服务器的更新解决了这个问题。另外，在那个项目中，我不得不知道，在Linux下的ext3 FS上，SVN比在Windows下的NTFS要快一个数量级。标记：运行在Windows上的虚拟机中的Linux花费十分之一的时间用于与VM运行在Windows上的Windows盒子竞争。 （我们总是试图用于Windows的OS ext3驱动程序，看看它是否会使SVN在Windows上的运行速度比它的本地FS版本要快，但是，在我们尝试之前，我已经离开了该项目。）

无论如何，不像你决定投入永恒的石头。您可以尝试一件事，在真实项目中对其进行彻底测试，并在稍后切换到其他服务器和协议。 （甚至有一个SVN命令来切换检出树的URL 。这可以用来切换协议，而无需重新检查所有内容。）

下面是我会考虑的关于协议的决定：If您有一个可用于登录SVN的AD或LDAP基础架构，请尝试使用http/https:协议选项之一。如果你没有这个，并且你不需要它，你可以通过SVN自己的方式登录，为什么不使用svn:协议提供的速度？

我从来没有见过人们使用WebDAV访问的SVN回购协议。 IME他们总是希望在访问每个网页时具有历史记录（WebDAV不提供此功能，AFAIK），因此他们使用SVN的网页前端之一。我从来没有检查过，但我只是假设像ViewVC之类的东西不关心他们用于访问回购协议的协议。

至于你想使用哪种发行版本 - 我认为这主要归结于个人喜好，因为下面的代码是相同的。我更喜欢我没有注册的下载和明确针对我想要安装它们的平台的发行版。但那可能只是我。

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

Answer 4

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

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

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

（这是我与一队的10个开发经验）