跟踪子存储库中的内部库

Question

我们正在开发一个内部框架，供多个项目使用。 我们的想法是将整个框架作为一个 mercurial 进行跟踪 每个项目的存储库的子存储库。这导致了以下 子仓库树（见thin-shell repository）：

ProjectMaster/
    Project/
    CommonLib/
    FrameworkMaster/
        Framework/
        CommonLib/

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

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

Answer 1

根据thin-shell repository 文档中的描述：

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/ 是否仅作为嵌套子存储库的占位符包含在内，或者它也有“真实”代码。如果 /FrameworkMaster/ 也有“真实”代码那么它也应该作为兄弟叶节点包含在下面）：

ProjectMaster/
    Project/
    Framework/
    CommonLib/ 

所以，回答你的问题：

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

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

• 具体来说，拥有两个 CommonLib 子存储库是否有意义？

如果 Project 和 Framework 都依赖于 CommonLib 的 same version 或 branch，那么同时拥有它是没有意义的地方。但是，如果出于某些遗留原因项目和框架需要 CommonLib 的 不同 版本 或 分支，那么在这两个地方都有 CommonLib 确实有意义。

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

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