Version control 跟踪子存储库中的内部库

我们正在开发一个内部框架，几个项目将使用该框架。 我们的想法是将整个框架作为一个mercurial进行跟踪 每个项目存储库的子存储库。这导致了以下结果： 子回购树（参见）：

• 这对你有意义吗？有没有更好/更简单的方法来处理这些问题 不涉及子存储库的依赖项
• 具体来说，两个CommonLib子存储库都有意义吗
• 如果不是，Project使用FrameworkMaster/CommonLib有意义吗？这 如果依赖关系更复杂，可能会变得混乱
• 您将在哪里打开功能分支？在主人身上？只有在相关的 子存储库？
  • 如果主机上没有功能分支，则每次克隆 最后，您将获得最后一次提交的subrepo状态，这可能会导致 任意随机特征分支中的任意子回购。非常混乱
  • 如果主控台上有要素分支，则仍然需要要素分支 在至少一个次级回购中，以避免出现未命名的头

一般来说，这个解决方案听起来很难使用。有什么建议吗？

根据文档中的描述：

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable. 

您描述的结果结构具有嵌套的子存储库，其中包含“真实”代码，因此不推荐使用这种方法。根据mercurial文档，建议的结构如下所示（我不知道/FrameworkMaster/是否仅作为嵌套子存储库的占位符包含，或者它也有“real”代码。如果/FrameworkMaster/也有“real”代码，那么它也应该作为同级叶节点包含在以下内容中）：

因此，要回答您的问题：

• 这对你有意义吗？有没有更好/更简单的方法来处理这些不涉及子存储库的依赖关系

更好/更简单的方法是使用薄壳存储库来简化复杂的依赖关系

• 具体来说，两个CommonLib子存储库都有意义吗

如果项目和框架都依赖于相同的CommonLib版本或分支，那么在这两个地方都使用它是没有意义的。但如果出于某些遗留原因，项目和框架需要不同的CommonLib版本或分支，那么在这两个地方都使用CommonLib是有意义的

• 您将在哪里打开功能分支？在主人身上？仅在相关子存储库中

---

这里不确定您所说的要素分支是什么意思。你是想在这里说“未来”吗？

很有趣。我想“FrameworkMaster”可能只供框架开发人员使用。通过功能分支，我提到了用于开发特定功能的命名分支（请参阅）。在这种情况下，为FrameworkMaster提供单独的薄壳存储库也很有意义，它只包括框架和CommonLib子存储库。这样，项目开发人员和框架开发人员就可以在相同的代码基础上工作。

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable. 

ProjectMaster/
    Project/
    Framework/
    CommonLib/