3

我多次阅读教程，我觉得我仍然缺少一些东西。我将尝试给出一个具体的场景。请帮我找出我错在哪里。

假设我有一个每个人都认为是“中心”的存储库。这意味着每个新开发人员都从它克隆并从中拉/推。Central 包含三个文件夹-

  • Infra（即将成为共享代码）
  • .hg
    • infra.txt
  • 开发者1
    • dev1.txt
    • .hgsub （其中有一行 --> infra = (path of infra) ）
    • 基础设施（次回购）
      • .hg
      • infra.txt
  • 开发2
    • dev2.txt
    • .hgsub（与 dev 1 相同 - infra = (path to infra) ）
    • 基础设施（次回购）
      • .hg
      • infra.txt

现在，假设一个开发者克隆了 dev1，而另一个开发者克隆了 dev2。我看到的是，当 dev1 的开发人员更改 infra 并将更改推送到中央存储库时，dev2 开发人员了解 infra 更改的唯一方法是手动搜索 infra 中的传入更改集作为子-存储库。一般来说，这意味着如果我的项目有很多子存储库（它们本身可能包含更多的子存储库），除了手动检查我的子存储库之外，我无法知道更改。

我认为这不是工作方式......有人可以帮忙吗？

提前致谢，

埃亚尔

4

2 回答 2

3

我想我找到了更好的东西。在检查存储库中的传入更改集时，您可以使用 --subrepos 标志。

这将递归搜索传入的变更集，并向我们展示可以在其中提取变更集的子存储库。

这样，人们可以控制更改了哪些子存储库，以及她是否想要在这些子存储库中获取最新文件。

于 2011-03-11T13:23:17.960 回答
1

您将不得不为每个存储库拉取。您可能认为这很乏味，但 mercurial 不会决定为您将更改拉入您的存储库 - 这是一件好事。

您可以做的是创建一个简单的批处理脚本，对每个存储库运行“hg pull”命令。这至少使该过程自动化，因此当您真正想从所有存储库中提取时感觉不那么乏味。

我们将所有子存储库移到一个存储库中，这使得管理需要更改所有库的更改/新功能变得更加简单。

我喜欢子存储库，但我认为它们最适合拉入其他人维护的整个存储库，并且保持相当稳定。当有很多更改时，您需要大量的纪律和一定数量的脚本来将手动工作降至最低。

于 2011-03-11T11:52:30.880 回答