我们有一个超过 6GB 的 Hg 存储库和 150,000 个变更集。它在大型应用程序上已有 8 年的历史。在过去的 8 年中，我们使用了分支策略。在这种方法中，我们为一个功能创建一个新分支，完成后，关闭该分支并将其 merge 到 default/trunk。在将更改推送到默认值后，我们不会修剪分支。
随着我们的 repo 的增长，使用它变得越来越痛苦。我们喜欢在每个文件上拥有完整的历史记录并且不想丢失它，但我们希望使我们的存储库大小更小。
我一直在研究的一种方法是拥有两个单独的存储库，一个“工作”存储库和一个“存档”存储库。工作存储库将包含最近 1 到 2 年的历史记录，并且将是每天克隆和推送/拉出的存储库开发人员。 Archive repo 将包含完整的历史记录，包括推送到工作 repo 中的新变更集。
我找不到正确的 Hg 命令来启用它。我能够使用 hg convert <src> <dest> --config convert.hg.startref=<rev> 创建一个工作仓库.然而，Mecurial 认为这是一个完全不同的存储库，打破了我们的工作存储库和存档存储库之间的任何关联。我无法找到一种方法将推送到工作存储库的变更集 merge/拼接到存档存储库中并维护统一的文件历史记录。我试过 hg transplant -s <src> ，但这导致了几个“跳过清空的变更集”消息。我不清楚为什么 hg transplant命令认为这些变更集是空的。另外，如果我要让它工作，有没有人知道它是否维护文件的历史记录，或者我的存储库是否会将移植的部分视为单独的部分，可能显示为删除/创建或其他内容？
任何人都有解决方案来启用这种工作/存档方法，或者有一种可能对我们有用的不同方法？我们必须保留完整的文件历史记录，以使历史研究变得简单。
谢谢
最佳答案
您可能会遇到已知错误 与底层存储压缩。 150,000 次修订的 6GB 很多。
这个存储问题通常在非常分支的存储库中遇到，在存储每个修订内容的内部数据结构上。此错误的当前修复可以将存储库大小减少多达十倍。
可能的快速修复
您可以盲目地尝试对问题应用当前的修复程序，看看它是否缩小了您的存储库。
[格式]
稀疏转速日志 = 是
hg debugupgraderepo --optimize redeltaall --run (这需要一段时间)其他一些改进也在 4.7 中默认开启。所以升级到 4.7 并运行
debugupgraderepo应该在所有情况下都有帮助。更精细的诊断
你能告诉我们
.hg/store/00manifest.d的尺寸是多少吗？文件与 .hg/store 的完整大小相比?另外，你能提供使用
hg debugrevlog -m的输出吗？其他原因？
存储库大小增长的另一个原因是要在其中提交大型(通常是二进制文件)。你有吗？
关于Mercurial Repo Living Archive，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51935322/