我们正在开发一个内部框架，该框架将使用几个项目。这个想法是将整个框架跟踪为一个杂物每个项目存储库的子修订版。这导致了以下subrepo树（请参阅薄壳存储库）：
ProjectMaster/
Project/
CommonLib/
FrameworkMaster/
Framework/
CommonLib/
- 这对您有意义吗？是否有更好/更简单的方法来处理这些依赖性不涉及子重新构件？
- 具体来说，拥有两个常见的子重新构件是有意义的吗？
- 如果没有，项目使用Frameworkmaster/CommonLib是否有意义？这如果依赖性更复杂，可能会变得凌乱。
- 您将在哪里打开功能分支？在主人上？仅在相关子修订版？
- 如果您在主人上没有特色分支，则每次克隆存储库您最终获得了最后一个提交的子对状态，任何随机特征分支中的任何子repo。非常混乱。
- 如果您在主人上有特色分支，则仍然需要一个功能分支在至少一个子雷普中，以避免在那里没有命名的头。
通常，此解决方案听起来很难使用。有任何建议吗？
根据薄壳存储库文档中的描述：
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/是否作为嵌套子重新构件的位置持有人或它也具有"真实"代码。然后，它也应包含在以下作为同级叶节点）：
ProjectMaster/
Project/
Framework/
CommonLib/
所以，回答您的问题：
- 这对您有意义吗？是否有更好/更简单的方法来处理这些依赖关系，而这些依赖项不涉及子重新构件？
更好/更简单的方法是使用薄壳存储库来简化复杂的依赖关系。
- 具体来说，拥有两个常见的子重新构件是有意义的吗？
如果项目和框架都取决于 same 版本或 commonlib的分支 地方。但是，如果出于某些遗产原因，项目和框架需要不同的 version 或 branch commonlib的，那么在两个地方拥有CommonLib确实很有意义。
- 您将在哪里打开功能分支？在主人上？仅在相关的子修订版中？
不确定这是您对特征分支的意思。您是要在这里说"未来"？