选择一个Subversion服务器

Question

选择一个Subversion服务器

7

在选择版本控制工具时，我选择了Apache Subversion (以及主要的Subversion客户端AnkhSVN / TortoiseSVN)。现在我正在尝试选择SVN服务器以提供对SVN存储库的远程访问。我看过了其中的几个：

我已经在虚拟机中安装了每个服务器进行测试，但没有发现足够的差异来选择任何一个特定的服务器。现在我有几件事情需要决定。

协议
供应商
SSL

1. 我读过HTTP比SVN协议要慢得多。虽然我的项目通常不会太大（真正耗时的只有最初的导入部分），但我确实想获得SVN的性能优势，并避免我的HTTP日志被SVN条目淹没 （至今无法将其分离成单独的LOG文件）。

然而，我喜欢使用Apache模块或VisualSVN提供的Web界面。我真的不需要向他人提供我的东西（甚至远离我的系统也是如此），因此这并不是关键，但它确实可以实现可扩展性。

2. 在选择协议后（假设我必须选择），我需要帮助决定使用哪个供应商。我最初使用了Tigris distro中的Apache模块。我已经移除了它（嗯，只是禁用了它），目前正在使用VisualSVN（它是HTTP，因此速度较慢）。我看到一些人支持Sharp和Silk，但它们似乎是较小的，独立的distros。
另一方面，Collabnet似乎比我需要的更复杂。基本上，除非我可以说服其中一个，否则我主要只是在Tigris和VisualSVN之间进行选择。

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

我想我甚至可以使用本地仓库；我认为它会是最快的。然而，我更喜欢一个更正式的解决方案，以防我扩展。（我考虑只使用TortiseSVN客户端在本地执行服务器的工作。）

所以，总之，我需要一些关于使用哪个服务器的建议。如果我能让VisualSVN提供用于Web的HTTP接口，但也为客户端提供SVN协议，最好每个协议都有SSL选项，那将是很棒的。这可能吗？会不会太麻烦（我真的想回到我的项目上，而不是所有这些元工作）。

谢谢。

（目前）单一系统，较老的P4，Windows，1GB SDRAM
（目前）单一开发者（我）
（目前）相对较小的项目（<2MB）
无数个项目（>100个独立应用程序、游戏、库、网站等）
需要外部依赖项（特别是我的自己的库以及第三方头文件、Boost等）
? 嗯，还有什么...

- Synetech

3

我还是新手，但我猜这个问题应该在Serverfault上适当地提问：http://serverfault.com - chuckharmston

我有几个使用HTTP访问的100Mb项目。性能根本不是问题。除非性能真正成为问题，否则我不会担心或烦恼svn://。 - nos

4个回答

2

关于访问速度：我曾经见过一个Apache https: SVN服务器需要硬件升级。我记得主要是由于内存不足，导致众多Apache进程争夺机器资源而减慢了速度。但那是20个开发人员合作完成的项目，他们检出了20GB的树（里面有很多二进制文件，经常会更改）。换成一台性能适中的服务器后问题得以解决。

此外，在那个项目中，我必须学习到Linux下ext3文件系统上的SVN至少比Windows下的NTFS快一个数量级。请注意：在Windows上运行的虚拟机中的Linux更新所需时间只有与VM运行的Windows竞争的十分之一。（我们一直打算尝试使用Windows的OS ext3驱动程序，并查看是否可以使SVN在Windows上比本地文件系统更快。但是，在我们进行尝试之前，我已离开该项目。）

无论如何，你做出的决定并不是永远不可更改的。你可以尝试一种方法，在真实项目中进行彻底测试，然后稍后切换到另一台服务器和协议。（甚至有一个SVN命令可以切换已检出树的URL。这样你就可以在不重新检出所有内容的情况下切换协议。）

以下是我考虑决定协议时会考虑的因素：如果你有一个工作的AD或LDAP基础架构，想利用它来登录SVN，请尝试其中一个http/https:协议选项。如果你没有这个需求，并且你可以使用SVN自己的登录方式，为什么不使用svn:协议提供的速度呢？

我从未见过人们使用WebDAV访问SVN存储库。在我的经验中，当他们通过Web进行访问时，他们总是想要有历史记录（据我所知，WebDAV无法提供此功能），因此他们使用了其中一个用于SVN的Web前端。我从未检查过，但我只是假设像ViewVC之类的东西不关心它们用于访问存储库的协议。

至于你想要使用哪个发行版——我认为这主要取决于个人喜好，因为代码本质上是相同的。我更喜欢不必注册即可下载并专门针对我想安装的平台的发行版。但这可能只是我的个人偏好。

然而，有一个你可能需要考虑的硬性事实，那就是如果你的存储库可以从Internet访问：在SVN项目发布新版本时，不同的发行版需要多长时间才能跟上。由于这些可能是安全修复程序，你可能更喜欢通常提供更快修复的那些发行版。

- sbi

1

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

我注意到，对于大文件的提交或检出，传输速度接近网络速度。而对于大量小文件的检出或提交，HTTP请求的开销更加明显。

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

（这是我和一个由10名开发人员组成的团队的经验）

- Michael Shaw

0

我在家和工作中都使用CollabNet。它表现得很好- 没有性能方面的抱怨。

- duffymo

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lasse V. Karlsen · Accepted Answer

编辑：在阅读其他答案之后，有一件事情我想提到。如果您尝试一个服务器，您要求其服务的存储库与您要求另一种类型的服务器服务的存储库没有区别。

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

当时发布了VisualSVN Server，我安装了它，并对其感到非常满意。

然而，速度问题使我转向了作为Subversion命令行包的一部分发货的主svnserve服务器。

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

首先，我的类库中制作的每个项目都由我的密钥签名。第二，像SQLite和NUnit等外部第三方库被添加为外部引用。

每个项目都有自己的外部引用。我这样做是为了能够制作一个新的应用程序项目，然后将新的外部引用添加到我需要的类库部分中，并使这些引用完整。如果我的.NET类库解决方案中有一个外部引用用于签名密钥文件，并且该文件未作为任何单个项目的一部分而位于磁盘上，但在我的解决方案中与所有项目都不相关，则无法使用该文件。

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

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

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

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

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

我的建议是尽可能使用主svnserve服务器。可能需要一些工作来了解授权和类似的配置文件，但仅仅是避免因速度而产生的烦恼（即根本没有速度方面的烦恼）很可能会超过这些工作带来的烦恼。