Question

我们正在开发一个多个项目将要使用的内部框架。我们的想法是将整个框架视为一个多变的每个项目的存储库的子存储库。这导致以下结果 subrepo tree（见thin-shell repository）：

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

这对你有意义吗？是否有更好/更简单的方法来处理这些不涉及子存储库的依赖项？
具体来说，同时拥有两个CommonLib子库是否合理？
如果没有，Project是否有意义使用FrameworkMaster / CommonLib？这个如果依赖关系更复杂，可能会变得混乱。
你会在哪里打开功能分支？在主人？只有相关 subrepository？
- 如果您在主服务器上没有功能分支，则每次克隆时都会存储库你最终得到最后一次提交的subrepo状态，这可能会放任何随机特征分支中的任何子参数。非常混乱。
- 如果您在主服务器上有功能分支，则仍需要功能分支在至少一个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/

所以，回答你的问题：

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

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

具体来说，同时拥有两个CommonLib子库是否合理？

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

你会在哪里打开功能分支？在主人？只在相关的子库中？

这里不确定功能分支的含义。你是不是想在这里说“未来”？

跟踪子库中的内部库

1 个答案: