Mercurial：粒度存储库与版本控制中的大型存储库和共享第三方工具

Question

设想： 各种产品由较小的项目组合而成。每个产品在开发、发布和维护中都有几个不同的版本（错误/补丁/次要版本）。

大多数团队使用各种第三方工具和库进行开发和发布（常见的两个是用于开发的 XUnit 和用于产品的 AutoMapper）。他们是对这些工具/库进行有意义的版本控制的粉丝。

我似乎无法理解在 Mercurial 中组织结构的最佳方式。在中央 SVN 风格中，我会通过将第三方工具作为自己的项目进行组织，然后为项目进行小型构建以获取其他项目的输出，然后构建一个发布项目已建成的项目。所有内容都将位于一个层次结构中，

（开发分支）

Root/dev/ProjectX/
Root/dev/ProjectY/
Root/dev/ThirdParty/XXX -- could be a 3rd party lib
Root/dev/ThirdParty/YYY -- could be a 3rd party lib

（分支 1）

Root/release1/ProjectX/
Root/release1/ProjectY/
Root/release1/ThirdParty/XXX 
Root/release1/ThirdParty/YYY

（分支 2）

Root/release2/ProjectX/
Root/release3/ProjectY/
Root/release2/ThirdParty/XXX 
Root/release2/ThirdParty/YYY

等。

由于开发人员保持机器最新的方式（使用 NUGET 包管理器）第三方项目都必须位于 ThirdParty 文件夹中，以确保开发人员不必为每个项目都拥有这些库的多个副本项目。

我的问题是：

如果他们实施 Mercurial 应该实施类似的策略（大仓库）并在此处克隆/分支，或者他们应该在项目级别分解存储库并克隆/分支它们。在后一种情况下，他们会有产品/版本分支/存储库吗？我知道如果分布式模型从长远来看效果更好，他们会更喜欢它，即使学习新工作流程一开始很困难。

我读过 http://nvie.com/posts/a-successful- git-branching-model/ 和一些文章，但我仍然不确定如何组织。

Answer 1

基本上，您为每个产品、每个项目和每个第三方库创建一个单独的存储库，然后在 子存储库。在您的中央服务器（或多个服务器）上，我可能会设置如下所示的裸存储库结构：

  products/ProductA/
           ProductB/
           ProductC/   
  projects/ProjectA/
           ProjectB/
           ProjectC/   
thirdparty/ThirdPartyA/
           ThirdPartyB/
           ThirdPartyC/

这样，您的中央服务器上的每个存储库都只有一个副本。您不需要为每个分支创建单独的存储库，因为 Mercurial 可以在一个存储库中保存多个分支。

然后，当有人在本地存储库中签出产品时，您可以使用子存储库机制来签出相应项目和第三方库的工作树。在本地磁盘上，结构将如下所示：

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

这看起来与中央服务器上的不同，因为在那里您没有工作树，只有指向子存储库的指针。