Mercurial分支存储库与SUBREPOS

我试图确定人们如何使用“分支存储库”，同时也使用子存储库

假设我的repo Main包含一个解决方案文件（.NET），并填充了子repo a、B、C：

/Main
    - A
    - B
    - C
    MainSolution.sln

A、 B和C虽然在其他“主要”回购协议之间共享，但与主要项目紧密结合。因此，主回购协议的一个主要特征需要对子回购协议进行修改（即，它们是共享库，但开发非常活跃）

现在是添加功能的时候了。该功能太大，一个人无法处理，因此需要将代码推送到中央回购协议，以便其他人能够提供帮助。我们还需要能够回到特性开发开始之前的最后一个“稳定”代码，以防需要错误修复。我认为目前我有两个选择：（1）在主回购协议中创建命名分支，或（2）创建主回购协议的新克隆。由于存在次级回购，这两种选择通常不会产生影响

选项1）我认为，创建命名分支将允许提交/推送对子repo的修改，但只有在其Main克隆中更新到该分支的其他人才会受到影响，因为.hgsubstate文件是跟踪的。然而，次级回购将有一个新的头，因此（可能的）实验性特征最终会被推到中央回购。我理解正确吗

选项2）有许多人主张“不要使用命名分支，使用‘分支存储库’”，这些分支存储库实际上是主repo的克隆，但命名不同，存在于中央服务器上。这对我来说有点吸引力，因为它似乎能让事情保持分离（从而与灾难保持分离，因为同事——和我自己——仍在学习Mercurial）。但当涉及子存储库时，此工作流似乎完全中断，因为创建主repo的克隆不会创建新的、分离的子repo克隆。这是一个新的克隆，但它仍然指向相同的子库，因此对它们所做的更改将返回到子库中！我意识到这是故意的，这是Mercurial（对我来说）最酷的事情之一。但人们究竟是如何将分支存储库工作流与子存储库一起使用的呢？对于每个特性/实验/版本/任何内容，我将创建主repo的新克隆（在中央服务器上），创建子repo的克隆（在中央服务器上），并修改所有.hgrc/.hgsub路径以指向正确的中央repo，这是完全不可想象的

---

在这一点上，我只是想了解人们是如何处理一个复杂的项目以及如何使用分支存储库中的子repo的。有什么想法吗？

对于最终很可能合并到默认分支中的功能，我更喜欢命名分支。切换分支比切换回购容易得多

---

有了命名分支，您就不必担心意外地将不稳定的开发分支推到稳定的回购中。命名分支已经存在，但除非开发人员要求，否则无法通过更新检索。

您还有其他选择。例如，你可以使用书签。从1.9版开始，书签可以被推拉，它们不再只是本地的。由于您通常不希望开发“分支”在新功能完成后仍然作为命名分支存在，因此书签通常是更好的选择。我倾向于使用书签进行新的开发，并将真正的分支保存到发布的版本中

您还应该知道，子存储库不必按照您描述的方式在多个主存储库之间共享。实际上，您可以将子存储库存储在主存储库中（而不是将它们存储在与主repo相同的级别，或者完全存储在其他位置），这将使它们对每个主存储库都是唯一的，除非您可以在共享这些更改时从其他主repo中的子repo中推送和拉取。我通常是这样做的

---

不幸的是，没有白板很难解释其中的大部分内容，因此如果不清楚，请告诉我。

两件事。当您说除非开发人员要求，否则不会检索命名的分支时，您的意思是除非签出该分支，否则不会修改开发人员的工作副本，还是您指的是其他内容？据我所知，所有分支都是自动推拉的。此外，根本问题不是是否使用命名分支还是分支回购，而是在使用子存储库时如何使用分支存储库。但是谢谢你的回复！命名的分支将通过“hg pull”进行检索，但是如果开发人员没有明确更新到其他分支（例如“hg up-r”），他们的工作目录将不会更新到其他分支。在我看来，最好的方法是开发人员最难搞砸的方法。当单独的分支回购被意外地推到一起时，会出现“瓶子里的精灵”问题，这让我相信，在单个回购中命名分支更可取。YMMV。诚然，我可能错过了次级回购协议带来的一些额外的复杂性。祝你好运！有人能解释一下@MarkB在这里描述的“瓶子里的精灵”场景是什么吗？