为我的版本控制需求选择Apache Subversion后，为我的主要Subversion客户端选择 AnkhSVN / TortoiseSVN 。现在我试图选择SVN服务器来提供对SVN存储库的远程访问。我看了几个：
我已经在虚拟机中安装了每个以试用它们但是还没有找到足够的区别来充分区分它们以便选择任何特定的。现在我有一些我需要决定的事情。
1.我已经读过HTTP比SVN协议慢。虽然我的项目通常不是太大（实际上只是初始导入是耗时的部分），但我确实希望获得SVN的性能优势，以及避免我的HTTP日志充斥着SVN条目（我目前无法分离成一个单独的LOG文件）。
但我确实喜欢使用Apache模块或VisualSVN提供的Web界面。我真的不需要将我的东西提供给其他人（或者甚至是我自己远离我的系统），因此它不是 critical ，但它肯定允许扩展。
2.选择协议后（假设我有选择）;我需要帮助决定使用哪个供应商。我最初使用的是Tigris发行版中的Apache模块。我已经删除了（好吧，只是禁用它），并且我正在使用VisualSVN（这是HTTP，因此很慢）。我见过人们赞同夏普和丝绸，但他们似乎是较小的，独立发行
另一方面，Collabnet似乎比我需要的更精细。基本上，除非我能说服其中一个，我主要是试图在官方的底格里斯和VisualSVN之间做出选择。
3.我也尝试过乱用SSL而没有太大的成功（我买不起真正的CA，所以我在VisualSVN中使用自签名证书）。我很乐意使用SVN + SSH / HTTPS，但如果我在自己的系统上使用它，那么就没有必要，如果我在外部使用它，那么我的自签名证书将无济于事。
我想我甚至可以使用本地存储库;我认为这将是最快的。但是，如果我扩展，我宁愿选择更正式的解决方案。 （我考虑过只使用TortiseSVN客户端在本地完成服务器的工作。）
总而言之，我需要一些关于使用哪个服务器（ s ？）的建议。如果我可以让VisualSVN为Web使用提供HTTP接口，并且还在SVN协议上提供用于客户端，最好在每个客户端上选择SSL，那将是多么美妙的事情。那可能吗？是不是太多工作（我真的想回到我的项目而不是所有这些元工作）。
非常感谢。
修改
我认为我应该提供一些关于我的情况的信息来澄清事情。
答案 0 :(得分：5)
编辑：在阅读完其他答案之后，我认为应该提一件事。如果您尝试使用一台服务器，那么您要求它提供的存储库与您要求其他类型服务器提供服务的存储库没有区别。
换句话说，如果您决定立即尝试使用一台服务器，则可以稍后切换到其他类型的服务器，而不会丢失您的存储库。当然，工作副本以及您在项目中所做的任何绝对外部参考都必须进行更改，但您可以保留存储库中的历史记录和所有内容。
我在宣布时安装了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服务器，通过大量配置文件进行处理，并使用Apache而不是通过VisualSVN服务器设置Subversion，只是为了确保它不仅仅是VisualSVN，而且我已经确认我观察到的速度不是VisualSVN团队的工作。似乎HTTP协议或Apache模块并不那么快。
我的建议是尽可能使用主svnserve服务器。可能需要一些工作才能了解配置文件的授权等等，但单独的刺激因素（即对速度没有任何刺激）将超过这一点。
答案 1 :(得分：2)
重新访问速度：我看到一个需要硬件更新的Apache https: SVN服务器。我似乎记得它主要是缺乏内存，这减慢了竞争机器资源的众多Apache进程。但是，有20个开发人员在一个项目上进行合作，其中一个20GB的签出树（其中有许多二进制文件经常更改）。对适度配备的服务器的更新解决了这个问题。
此外，在那个项目中，我必须知道Linux下的ext3 FS上的SVN比Windows下的NTFS快一个数量级。标记：在Windows上运行的虚拟机中的Linux花了十分之一的时间来更新与VM运行的Windows框进行竞争。 （我们总是打算尝试Windows的操作系统ext3驱动程序，看看这是否会使Windows上的SVN速度比原本FS更快。但是，在我们尝试之前，我离开了项目。）
无论如何，它并不像你所决定的那样永远被铸成石头。您可以尝试一件事，在实际项目中彻底测试，然后切换到不同的服务器和协议。 （甚至还有一个SVN命令来切换已检出树的URL 。这可以用来切换协议而无需重新检查所有内容。）
以下是我将考虑决定协议的内容：如果您希望利用有效的AD或LDAP基础结构登录SVN，请尝试使用http / https:协议之一选项。如果您没有这个，并且您不需要它，并且您可以通过SVN自己的方式登录，为什么不使用svn:协议提供的速度？
我从未见过人们使用WebDAV访问的SVN回购。 IME他们总是希望在访问每个Web时具有历史记录（WebDAV不提供此功能，AFAIK），因此他们使用了一个用于SVN的Web前端。我从来没有检查过，但我只是假设像ViewVC之类的东西并不关心他们用来访问回购的协议。
至于你想要使用的发行版 - 我认为这主要取决于个人喜好，因为底层的代码无论如何都是一样的。我更喜欢我没有注册的下载和明确针对我想要安装它们的平台的发行版。但那可能就是我。
但是，如果您的存储库可以从Internet访问，那么您可能需要考虑一个难以理解的事实：当SVN项目制作新的点发布时，它在过去需要多长时间才能赶上不同的发行版。由于这些可能是安全修复程序，因此您可能更喜欢通常更快地提供修复程序的修复程序。
答案 2 :(得分：1)
我们使用在CentOS 5.3下运行的Apache从XEN虚拟机内部提供的HTTP提供SVN存储库。
我观察到在大文件上执行提交或签出，以接近网络速度传输该文件。在检出或提交大量小文件时，HTTP请求的开销更加明显。
与编译代码中的时间表相比，SubVersion不被视为公司内部的瓶颈。
（这是我与10位开发人员组成的经验）
答案 3 :(得分：0)
我在家里和工作中使用CollabNet。一切都很好 - 没有表现的抱怨。