是什么决定了SVN 1.6合并操作的速度

Question

我很惊讶将任何特定分支的非常小的变化合并到主干中需要多长时间; 在仅仅2k长的单个文本文件中合并几行文本的1-2分钟.

如果可能的话,我希望能更快地融合,但不知道从哪里开始.我做了一个快速谷歌和缓慢合并的可能原因似乎包括以下任何和所有: -

• 大型仓库大小(在磁盘大小和修订数量方面).
• 大型源代码树(显然SVN必须向下爬树才能计算出更改)
• SVN服务器/客户端的版本
• 非常大(几MB)文件(我们没有非常大的单个文件,所以我怀疑这会影响我们)

我想我真的想知道如何找出上述哪一点让合并变得如此缓慢.

现在我不知道它是在客户端工作还是在服务器上工作花费最多的时间(我怀疑它是客户端,因为服务器上的CPU使用量不大).我确实认为可能是大量的mergeinfo累积了100多个合并,但我已经做了一个测试,我从一些分支中删除了所有合并信息然后进行了合并,发现同样的慢.

所以我想问的是: - *如何诊断/分析SVN活动？*基于以下信息,是否有一些非常明显的因素导致性能不佳？

谢谢

克里斯

以下是有关SVN设置的一些事实/数据

• 我们的SVN存储库有大约32000个修订版.
• 磁盘上的回购大小:8.3GB
• 我们的开发分支机构每个都有大约1400个版本化文件夹(19,000个版本化文件)
• SVN服务器:1.6.6(r40053)(在Ubunto Lucid Lynx上运行的Apache中托管)
• 我在Win7上使用的是1.6.9龟(虽然团队的其他成员使用SmartSVN,他们报告的速度相同).

编辑

可能值得补充的是,当我们分支/合并时,我们从trunk分支并始终将整个分支合并回trunk.所以mergeinfo都在trunk(和branches)文件夹中.

结论

在我的情况下,似乎是磁盘访问是合并过程中的瓶颈 - 当我将源树从我的硬盘移动到我的SSD时,同样的合并从50 +/- 5s到7 +/- 1s.
合并期间在进程资源管理器中观察乌龟SVN进程非常明确:在我的硬盘上进行合并时,I/O字节在大部分时间内介于500kb/s和3Mb/s之间.在SSD上,I/O字节高达10-20Mb/s.[相当令人困惑的是,我的硬盘驱动器上的某些合并速度(和I/O字节同样很高)与我的SSD上的相似 - 在这些情况下,我假设正在读取的很多文件已经在Windows文件缓存中].

我发现以下所有增加的合并速度

• 从源代码层次结构深处的文件夹合并:这对于我们在"现实生活"中的选择并不是真正的选择,因为如果没有在"主干级"文件夹中记录合并跟踪变得几乎不可能,但确实显示合并很多较小的树木使这个过程更快.
• 减少正在合并的工作集的大小有帮助(假设您使用"工作集"深度合并选项而不是完全递归) - 所以通过简单地删除文件夹(从我的工作集下干线)增加速度.

Answer 1

您还可以尝试合并一棵较短的树，看看它是否返回得更快，看看较小的树是否会产生影响。

注意：最新版本中有很多与合并相关的改进，请查看以下链接

http://svn.apache.org/repos/asf/subversion/tags/1.6.11/CHANGES

升级到最新版本可能会有所帮助。