为何查看合并修订版的svn log -g命令执行耗时极长？如何解决？

我来帮你拆解下这个问题——我之前也帮不少开发者处理过类似的SVN合并历史查询卡顿的情况，下面从原因和解决办法两方面详细说说：

为什么svn log -g会越用越慢？ #

• 合并追踪的底层开销：-g（也就是--use-merge-history）选项的核心是帮你追踪所有合并操作关联的提交，这意味着SVN需要遍历每一个提交的mergeinfo属性，梳理分支间的合并关系。当仓库积累了上千次提交和大量合并后，SVN要加载、计算的元数据量会呈指数级增长，磁盘IO和内存消耗都会飙升，自然就慢了。
• 元数据碎片化：长期的提交、合并会让版本库的元数据（比如存储合并信息、版本属性的文件）变得碎片化。SVN查询时需要反复读取分散在磁盘不同位置的小文件，这比读取连续的大文件效率低得多。
• 旧版本库格式的限制：如果你的版本库还是用早期的FSFS格式（比如SVN 1.7及以前的版本），没有启用后续版本的优化特性（比如数据分片、打包存储），随着版本号升高，性能下降会特别明显。

可以试试这些解决办法 #

• 优化版本库存储
  • 先执行svnadmin pack：这个命令会把版本库中分散的版本数据打包成紧凑的格式，大幅减少磁盘IO次数。执行前记得先备份版本库，并且确保没有其他用户在提交代码。
  • 升级版本库格式（SVN 1.8+支持）：运行svnadmin upgrade可以把旧的FSFS格式升级到支持分片（sharding）的版本，把版本数据拆分到多个目录，避免单个目录文件过多导致的访问缓慢。
• 缩小查询范围
  • 不要每次都查全量历史，指定版本范围，比如svn log -g -r 4000:4913，只看最近几百个版本的合并历史。
  • 用--limit限制返回条数，比如svn log -g --limit 100，只看最新的100条带合并信息的提交，速度会快很多。
• 缓存查询结果
  • 如果需要频繁查看合并历史，可以写个简单的脚本，定期执行svn log -g并把输出保存到本地文件，需要时直接看缓存文件就行，不用每次都重新查询版本库。
• 升级SVN版本
  • 较新的SVN版本（比如1.10及以后）对合并历史的查询逻辑做了不少优化，包括对mergeinfo存储的改进，升级到新版本后，svn log -g的执行速度可能会有明显提升。

内容的提问来源于stack exchange，提问作者bobeff