我们有一个超过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命令认为那些变更集是空的。另外，如果我要执行此操作，是否有人知道它是否保留文件的历史记录，或者我的回购协议是否会将移植的部分视为单独的部分，也许显示为删除/创建之类的东西？
任何人都有解决方案以启用此工作/存档方法，或者采用其他可能对我们有用的方法？保持完整的文件历史记录以简化历史记录研究非常重要。
谢谢
答案 0 :(得分：5)
您可能会使用基础存储压缩功能找到一个已知错误。 150,000个修订版需要6GB的存储空间。
此存储问题通常在非常分支的存储库，存储每个修订内容的内部数据结构上遇到。该错误的当前修复程序可以将存储库的大小减少多达十倍。
您可以盲目尝试针对该问题应用当前修复程序，并查看其是否会使您的存储库缩水。
将以下内容添加到您的存储库配置中：
[格式] sparse-revlog =是
hg debugupgraderepo --optimize redeltaall --run（这需要一段时间）默认情况下，4.7中还启用了其他一些改进。因此，升级到4.7并运行debugupgraderepo在所有情况下都将有所帮助。
您能告诉我们.hg/store/00manifest.d文件的大小与.hg/store的完整大小相比吗？
此外，您是否可以将hg debugrevlog -m的输出用于
存储库大小增加的另一个原因是要在其中提交大文件（通常是二进制文件）。你有吗？
答案 1 :(得分：0)
问题是每个修订的哈希ID是根据包括父ID在内的许多项计算的。因此，当您更改父项时，您也会更改ID。
据我所知，没有很好的方法来执行此操作，但是我对一些回购协议做了类似的操作。坏消息是它需要一连串的仓库，批处理文件和拼接图才能完成。
理想情况下，我要描述的大部分工作仅执行一次，然后每次您想要对其进行更新以引入最新提交时，都对相同的现有存储库运行相同的脚本。
我要这样做的方法是拥有三个存储库：
Working的第一个提交是Archive中所有原始提交的压缩，因此，当您将Working代码拖入Archive时，您将把该提交扔掉，并将第二个Working提交重新放在Archive的旧提示上
停止：如果要执行此操作，请在尝试之前备份现有的存储库，尤其是“存档”存储库，如果在其顶部运行该存储库，则可能会被废弃。也许还可以，但是我的良心没有任何问题！
将“工作”和“存档”都放入“合并”存储库中。
现在，您有了一个合并回购，其中包含两个完全独立的树。
创建一个拼接图。这只是一个文本文件，其中给出了子节点的哈希值及其提议的父节点的哈希值，并用空格分隔。
所以你的拼接图就像这样：
hash-of-working-commit-2 hash-of-archive-old-tip
然后使用splicemap选项运行 hg convert ，以将工作的第二次提交重新归档到存档的旧提示上。例如
hg convert --splicemap splicemapPath.txt --config convert.hg.saverev=true Merge Archive
您可能想尝试将其写到其他命名的存储库中，而不是第一次使用“存档”，或者您可以尝试将其写在现有“存档”的副本上，我不确定它是否可以使用，但是如果可以，可能更快。
一旦运行了此设置，就可以一次又一次地在现有存储库上运行相同的脚本，以更新为最新的Working修订版。只需从“工作”转到“合并”，然后运行hg convert将其放入“存档”。