我多次阅读本教程，我觉得我仍然缺少一些东西。 我只想尝试给出一个具体的场景。请帮我找到我的位置 错误。
假设我有一个每个人都认为是“中心”的存储库。这个 意味着每个新的开发人员都会从中克隆并从/向其拉/推。 Central包含三个文件夹 -
现在，假设一个开发人员克隆dev1，另一个克隆dev2。 我看到的是当dev1的开发人员改变infra并推动 在中央更改存储库，这是dev2开发人员知道的唯一方法 关于infra的变化是手动搜索传入的变更集 以下作为子库。一般来说，这意味着如果我的项目有很多 子存储库（可能包含更多的子存储库）， 我无法知道这些变化，除了超越我的 子手册库。
我认为这不是工作方式...... 有人可以帮忙吗？
提前致谢，
的Eyal
答案 0 :(得分：3)
我想我找到了更好的东西。 检查存储库中的传入更改集时，可以使用--subrepos标志。
这将以递归方式搜索传入的更改集，并向我们显示可以在其中提取更改集的子存储库。
通过这种方式，可以控制更改哪些子存储库，以及是否要在这些子存储库中获取最新文件。
答案 1 :(得分：1)
您将不得不拉动每个存储库。您可能认为这很繁琐，但是mercurial决定不会为您将更改添加到您的存储库中 - 这是一件好事。
您可以做的是创建一个简单的批处理脚本，对每个存储库运行'hg pull'命令。这至少可以使过程自动化，因此当您真正想从所有回购中获取时，感觉就会变得不那么乏味了。
我们将所有子项目移动到一个存储库中，这使管理更改/新功能变得更加简单，这需要对我们所有的库进行更改。
我喜欢subrepos，但我认为它们最适合拉入其他人保持相当稳定的整个存储库。当有很多变化时，你需要大量的纪律和一定数量的脚本来将手动工作降到最低。