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

【问题标题】：What determines the speed of an SVN 1.6 merge operation什么决定了 SVN 1.6 合并操作的速度
【发布时间】：2010-11-03 09:52:43
【问题描述】：

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

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

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

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

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

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

谢谢

克里斯

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

我们的 SVN 存储库有大约 32000 个修订版。
磁盘上的存储库大小：8.3GB
我们的每个开发分支都有大约 1400 个版本化文件夹（19,000 个版本化文件）
SVN 服务器：1.6.6 (r40053)（托管在 Apache 中，在 Ubunto Lucid Lynx 上运行）
我在 Win7 上使用 tortoise 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 文件缓存中].

我发现以下都提高了合并速度

从 & 合并到源层次结构更深的文件夹：这不是我们在“现实生活”中的真正选择，因为如果不记录在“主干级”文件夹中，合并跟踪几乎是不可能的，但确实显示合并小得多的树会使这个过程更快。
减小要合并的工作集的大小有助于（前提是您使用“工作集”深度合并选项而不是完全递归） - 因此只需删除文件夹（从我在主干下的工作集中）即可提高速度.

【问题讨论】：

5.00MB transferred in 29 minutes and 32 seconds .... 所以是的

标签： performance svn merge

【解决方案1】：

您也可以尝试合并一棵较短的树，看看它是否返回更快，看看较小的树是否有所作为。

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

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

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

【讨论】：

似乎是磁盘访问占用了我的合并大部分时间，因此合并较小的树更快 - 请参阅我问题的 cmets 结尾

【解决方案2】：

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

【讨论】：

感谢尼古拉的回复。我们也遵循您的分支/合并模式（即始终从主干文件夹而不是子文件夹分支）

【解决方案3】：

另一个因素是两个分支之间的相对增量。所以举个例子，如果你从主干分支出来，然后一个月后将主干合并到分支中，这相对来说会花费很长时间。另一方面，如果你每天从主干合并到你的分支，这会比较快。

【讨论】：