1

我们正在开发一个内部框架，多个项目将使用该框架。这个想法是将整个框架作为每个项目存储库的可变子存储库进行跟踪。这导致了以下子存储库树（请参阅瘦壳存储库）：

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

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

4

1 回答 1

2

根据瘦壳存储库文档中的描述：

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 的相同 版本或分支，那么在这两个地方都有它是没有意义的。但是，如果由于某些遗留原因，项目和框架需要不同 版本或分支的 CommonLib，那么在这两个地方都有 CommonLib 确实有意义。

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

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

于 2012-12-10T05:54:15.347 回答