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

Question

我很惊讶将一个非常小的更改从任何特定分支合并到主干中需要多长时间； 1-2 分钟合并几行文本，这些文本在一个只有 2k 长的文本文件中发生了变化。

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

大型 repo 大小(在磁盘大小和修订数量方面)。

大型源代码树(显然 SVN 必须爬下树才能解决更改)

SVN服务器/客户端版本

非常大(几 MB)的文件(我们没有非常大的单个文件，所以我怀疑这会影响我们)

我想我真的很想知道如何找出上述哪些点使合并如此缓慢。

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

所以我想问的是:-
* 如何诊断/分析 SVN 事件？
* 根据以下信息，是否有明显的原因会导致性能不佳？

谢谢

克里斯

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

我们的 SVN 存储库有大约 32000 次修订。

磁盘上的存储库大小:8.3GB

我们的开发分支每个都有大约 1400 个版本化文件夹(19,000 个版本化文件)

SVN 服务器:1.6.6 (r40053)(托管在运行在 Ubunto Lucid Lynx 上的 Apache)

我在 Win7 上使用乌龟 1.6.9(尽管团队的其他成员使用 SmartSVN 并且他们报告了相同的速度)。

编辑

值得补充的是，当我们分支/合并时，我们从主干分支并始终将整个分支合并回主干。所以所有的合并信息都在主干(和分支)文件夹中。

结论

就我而言，磁盘访问似乎是合并过程中的瓶颈——当我将源树从 HDD 移动到 SSD 时，相同的合并从 50 +/- 5 秒变为 7 +/- 1 秒。
在合并期间在进程资源管理器中观看乌龟 SVN 进程非常有说服力:在我的 HDD 上进行合并时，I/O 字节在大部分时间里都在 500kb/s 和 3Mb/s 之间。在 SSD 上，I/O 字节高达 10-20Mb/s。 [令人困惑的是，我的 HDD 上的某些合并与我的 SSD 上的合并速度相当(并且 I/O 字节也同样高)-在这些情况下，我假设正在读取的许多文件已经在 Windows 文件缓存中]。

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

从 & 合并到源层次结构更深处的文件夹:这对我们来说在“现实生活”中并不是一个真正的选择，因为如果没有记录在“主干级”文件夹中，合并跟踪几乎是不可能的，但确实表明合并很多较小的树使过程更快。

减少正在合并的工作集的大小有助于(前提是您使用“工作集”深度合并选项而不是完全递归) - 因此只需删除文件夹(从我的主干下的工作集)提高速度。

Answer 1

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

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

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

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