我们最近从一个6 Gb的存储库中迁移了一个3.5 Gb的SVN存储库。我们保留所有内部制作的软件以及许多小型共享组件。我们也做了很多标记。 Projects保留了它的二进制依赖项的副本，主要是libs。我们现在不能转移到GIT。
我们开发人员的第一印象是Subversion很慢，我一直告诉他们历史相关的操作，但也有优势。
通过mod_dav_svn访问自定义身份验证。授权将通过提交后挂钩实现，因为我们将一些项目外包一年并需要详细的安全规则。
我们希望优化访问权限：
我们的存储库布局如下：
\root
\proyect1
\trunk
<files>
\docs
\branches
\tags
\proyect1-1.2.3-beta
<files>
\proyect1-1.3.0
<files>
etc...
.
.
.
\proyectn
是否有其他优化与硬件无关，之前显示成功？我们的文件布局可以有所不同吗？
答案 0 :(得分：5)
我只会评论我所经历过的部分。
1）首先，它很大！通常最好将二进制文件和库保留在存储库之外，即使有时将所有内容放在一起也更方便。我们有这样的项目（我工作的地方），文件在存储库中没有它们的位置，并且占据了很多位置。它在每次结账或重要提交时都会杀死服务器，其他项目都很好。
通常，分离项目也是一个好主意，svn:externals您有足够的灵活性可以在必要时链接它们，并且您可以避免单点故障问题，巨大的存储库大小，更容易进行备份等等。
但你不能总是选择那些参数。
2）它是Linux Apache服务器，还是在Windows上运行？我看到两者之间存在很大差异，Windows版本往往较慢，对配置非常敏感。
3）我会用svnserve而不是Apache mod_dav_svn进行测试。网络上的负载较轻，当许多人共享同一台服务器时（这也取决于网络配置），这也可能是一个阻塞点。
4）你使用1.5，甚至更好，1.6？文件系统已得到改进，如果您从先前版本迁移，则执行转储/加载会得到回报，通常是（check this link also）。我们对大型存储库进行了一些测试并获得了几个百分点，但我们观察到的情况存在很大差异。
5）此外，您可以考虑这一点（来自Version Control with Subversion） - 尽管我从未尝试过这种特殊可能性：
从Subversion 1.6开始，FSFS文件系统具有多个可配置参数，管理员可以使用这些参数来微调其存储库的性能或磁盘使用情况。您可以在存储库的db / fsfs.conf文件中找到这些选项及其文档。
6）如果钩子脚本实施不当，可能会产生影响，从而增加了服务器交互的额外延迟。
7）TortoiseSVN使用日志缓存，它有时很烦人（它往往会锁定你无法删除的文件 - 如果你不知道它可能会令人惊讶）但在浏览日志时为用户提供更快的响应（除了是Windows上一个集成良好的客户端）。答案 1 :(得分：0)
简短回答：尝试 svnserve ！在一些基准测试中，我做了一段时间以前，对于大多数操作来说，比mod_dav_svn快几倍。
我们随后切换到svnserve并且到目前为止还没有回头，但是如果需要并且正确配置它们，您也可以并行运行两个服务器。
可以在http://www.ohrner.net/software/tipps_en.php / http://www.ohrner.net/software/tipps_de.php找到长篇故事和测量结果。
答案 2 :(得分：0)
对我们开发人员的第一印象是Subversion非常 慢，我一直告诉他们与历史有关的操作是 也有优势。
Apache Subversion是集中式版本控制系统。 SVN完全能够存储千兆字节（如果不是TB级）的数据，包括文本，二进制文件或艺术家资产。您甚至可以使其分布-使用svnsync或VDFS。多站点或分布式存储库可帮助您提高性能并在全球范围内部署您的版本。
请注意，现代Subversion比十年前的速度要快得多。
除了我想说的是，许多关于“ svn性能”的抱怨只是由1）执行访问扫描的防病毒或防火墙2）problems with SSL/TLS certificate revocation checks 3）网络问题引起的。