1

我们目前正在尝试将我们的 mercurial（在这种情况下是 Kiln 的古老版本）迁移到 BitBucket，我们立即遇到了大小问题（如果您不知道，BitBucket 施加了相当大的 2gb 回购限制 - 我们碰巧吹过）。

无论如何，我已经清理了过去的罪过：

  • 使用带有文件映射的转换（删除不应该在 repo 中的二进制文件/静态文件）
  • 为其他不应该在主仓库中的东西创建单独的仓库
  • 尝试使用 generaldelta 来减小大小（根据 https://www.mercurial-scm.org/wiki/ScaleMercurial）
  • 使用分支图尝试合并旧分支及其关联的变更集

即使有了这些步骤，我仍然有一个非常大的清单文件，尽管为存储库存储的“数据”缩小到“可管理”的大小（~600mb），但我的清单文件接近 700mb。

一些附加信息：通常，我们练习每个功能的分支并有两个分支跟踪环境：

  • 发布分支（部署到 staging 然后到 prod）
  • 默认分支（最初关闭发布，所有功能先在这里合并然后发布。此分支每两周死亡并重生）

这个工作流程的一个区别是默认本身永远不会被合并到发布（a la gitflow/hgflow）。这种单向流入默认会导致问题吗？

我们“只有”有 120 个开放的分支负责人，所以这似乎是可以管理的？

我显然在这里遗漏了一些步骤（否则回购完全被冲洗掉了）。

4

1 回答 1

0

只是为了将来参考，我遵循了上面蒂姆的建议。我的完整脚本最终看起来像这样：

hg --config format.generaldelta=1 clone --pull oldrepo oldrepo-generaldelta
hg --config format.generaldelta=1 clone --pull oldrepo-generaldata oldrepo-generaldelta2
hg convert --filemap filemap.txt oldrepo-generaldelta2 newrepo

正如蒂姆在他的链接答案中提到的 - 我们的清单从大约 700mb 下降到大约 40mb 与第二个克隆。

我可以优化 Mercurial 克隆吗？

于 2015-12-01T16:22:29.737 回答