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

Question

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

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

• 大型回购邮件大小（磁盘大小和修订版数量）。
• 大型源代码树（显然SVN必须向下爬树才能计算出更改）
• SVN服务器/客户端的版本
• 非常大（几MB）文件（我们没有非常大的单个文件，所以我怀疑这会影响我们）

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

现在我处于黑暗状态，无论是在客户端上工作还是在服务器上工作都花费最多的时间（我怀疑它是客户端，因为服务器上的CPU使用量并不大）。我确实认为可能是大量的mergeinfo累积了100多个合并，但我已经做了一个测试，我从一些分支中删除了所有合并信息，然后进行了合并，发现同样的缓慢。 / p>

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

由于

克里斯

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

• 我们的SVN存储库有大约32000次修订。
• 磁盘上的Repo大小：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文件缓存中]

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

• 合并来自＆amp;到源层次结构深处的文件夹：对于我们来说，这并不是“现实生活”中的一个选项，因为如果不在“trunk-level”文件夹中记录合并跟踪几乎是不可能的，但确实显示合并更小的树使得这个过程要快得多。
• 减少要合并的工作集的大小有帮助（假设您使用“工作集”深度合并选项而不是完全递归） - 所以只需删除文件夹（从我的工作集下干线）增加速度

Answer 1

您还可以尝试在较短的树中进行合并，以查找是否更快地返回以查看较小的树是否有所作为。

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

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

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

Answer 2

合并时我注意到的一件事是使用顶级目录的合并非常快。因此，将功能分支合并到主干或将一系列修订从主干合并到您的功能分支是很快的。但是，将工作副本中某个特定文件的更改合并得非常慢。出于这个原因，我总是分支整个主干，然后更改我需要的任何文件，然后合并整个东西。因此，如果您的分支是从一个主干的子目录创建的，这可能就是为什么它非常慢。

Answer 3

另一个因素是两个分支之间的相对差异。因此，例如，如果你从主干分支出来然后在一个月后将主干合并到分支中，相对来说这将需要很长时间。另一方面，如果您每天从主干合并到您的分支，这将相对较快。