为什么 mercurial 子存​​储库被认为是不得已的功能

Question

我对源代码控制相对较新，特别是反复无常。在我的工作场所，我们使用 mercurial。与团队中的正常情况一样，不同的人从事不同但相关的项目。这个想法是为“子项目”创建一个主仓库（用于项目 X）和子仓库。

实施这不是问题。但我很好奇为什么在 mercurial 的文档中他们考虑使用 subrepos 功能，"a feature of last resort"。

Answer 1

它创建了一种依赖关系，这种依赖关系恰好处于一个微妙的平衡点，即过于紧密的依赖关系无法保留在完全独立的项目中，而过于松散的依赖关系无法保留在同一个项目中。人们通常认为自己处于最佳位置，而实际上并非如此，尤其是当他们习惯于集中式版本控制的文件夹结构时。他们不记得他们为了避免维护多个集中式版本控制服务器带来的不便而将所有内容都塞进一个 repo 中，而不是因为项目本身之间存在某种内在的依赖关系。