如何将大型 mercurial 存储库分解为较小的存储库答案

【问题标题】：How to break a large mercurial repository into smaller ones如何将大型 mercurial 存储库分解为较小的存储库
【发布时间】：2011-09-12 22:14:38
【问题描述】：

这是 this question, 的副本，但特别是关于 mercurial。

我有一个巨大的颠覆存储库，我已将其转换为 mercurial。现在看起来像这样：

MassiveFolder/
   .hg/
   bin/
   common/
   projA/
   projB/
   ...
   projX/
   makefile
   README

我希望每个子项目都在其自己的存储库中进行跟踪，以获得更好的性能。请注意，它们都构建在同一个 bin 文件夹中。我不认为这会是一个问题，但我不确定我是否需要做任何事情来调整路径。可以安全地假设每个开发人员都会以相同的结构克隆存储库，但如果有某种方法可以创建一个可以确保这一点的元存储库，那就更好了。

有这样做的标准方法吗？我应该如何处理根文件夹中的 makefile 和自述文件等文件？

如果我必须通过其他一些不应该成为问题的过程重新导入到 hg。使用单体存储库执行标准操作需要的时间太长了，即使它已经把 svn 吹得水泄不通了。

【问题讨论】：

【解决方案1】：

您可以使用 Mercurial 的 Convert Extension（您可能已经知道，因为您将存储库从 SVN 转换为 HG）与 -filemap 选项一起为 SVN 子文件夹创建单独的 HG 存储库。您尤其需要 include 指令：

include 指令会导致一个文件或目录下的所有文件包含在目标存储库中，并排除不在包含规则下的任何其他元素。

然后，您可以使用Mercurial Subrepositories 在所需的文件夹结构中设置存储库：

子存储库是一项允许您将存储库集合视为一个组的功能。这将允许您将项目及其关联库作为一个组进行克隆、提交、推送和拉取。

【讨论】：

【解决方案2】：

我在较小的存储库上成功使用的方法如下：

确定列出较小的存储库以及它们如何相互关联。

如果子项目与顶级 Makefile 交织在一起，您可以添加顶级存储库，其中子存储库位于较小的存储库中。

这种方法保留了历史，不会强迫人们重新克隆。如果你对爆炸历史没问题，convert 没问题，并且会缩小存储库大小。

一个（或几个）警告：与单一存储库操作的简单性相比，子存储库有很多困难的行为。有些操作是递归的，有些则不是。合并特别是递归，这通常让我很适合。确定整个系统状态可能具有挑战性，尤其是随着子存储库数量的增加（我正在帮助管理一个拥有超过 100 个子存储库的项目，是的，这是处理它的合乎逻辑和最佳方式)。

【讨论】：