水星回购生活档案

Question

我们有一个超过6GB的Hg存储库和150,000个变更集。在大型应用程序上已有8年的历史。在过去的8年中，我们一直采用分支策略。在这种方法中，我们为功能创建一个新分支，完成后，关闭该分支并将其合并到default / trunk。将更改推入默认设置后，我们不会修剪分支。

随着我们回购协议的增长，使用它变得越来越痛苦。我们喜欢在每个文件上都有完整的历史记录，并且不想丢失它，但是我们希望使我们的回购规模小得多。

我一直在研究的一种方法是拥有两个单独的存储库，即“工作”存储库和“存档”存储库。工作回购将包含最近1到2年的历史，并且每天都会被克隆和推/拉出回购开发人员。存档存储库将包含完整的历史记录，包括推送到工作存储库中的新变更集。

我找不到正确的Hg命令来启用此功能。我能够使用创建工作仓库hg convert <src> <dest> --config convert.hg.startref=<rev>。但是，Mecurial认为这是一个完全不同的回购协议，从而打破了我们的工作库和存档库之间的任何关联。我无法找到一种方法来将推送到工作存储库的变更集合并/拼接到存档存储库中，并保持统一的文件历史记录。我尝试过hg transplant -s <src>，但是导致了一些“跳过清空的变更集”消息。我还不清楚为什么该hg transplant命令为什么认为这些变更集是空的。另外，如果我要执行此操作，是否有人知道它是否保留文件的历史记录，或者我的回购协议是否会将移植的部分视为单独的部分，也许显示为删除/创建之类的东西？

任何人都有解决方案以启用此工作/归档方法，或者有另一种可能对我们有用的方法？保持完整的文件历史记录以简化历史记录研究至关重要。

谢谢

Answer 1

您可能会使用基础存储压缩来发现一个已知的错误。150,000个修订版需要6GB的存储空间。

在非常分支的存储库中，在存储每个修订内容的内部数据结构上，通常会遇到此存储问题。针对该错误的当前修复程序可以将存储库大小减少多达十倍。

可能的快速修复

您可以盲目尝试针对该问题应用当前修复程序，并查看其是否缩小了您的存储库。

• 升级到Mercurial 4.7，

• 将以下内容添加到您的存储库配置中：

  [格式] sparse-revlog =是

• 运行hg debugupgraderepo --optimize redeltaall --run（这需要一段时间）

4.7中默认还启用了其他一些改进。因此，debugupgraderepo在所有情况下，升级到4.7并运行都应该会有所帮助。

更精细的诊断

您能告诉我们.hg/store/00manifest.d文件的大小是.hg/store多少吗？

另外，您可以提供与以下内容一起使用的输出吗？ hg debugrevlog -m

还有其他原因吗？

存储库大小增加的另一个原因是要在其中提交大文件（通常是二进制文件）。你有吗？