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，他们应该实现simmilar策略(大回购(并在这里克隆/分支，或者他们应该在项目级别分解存储库并克隆/分支这些。在后一种情况下，他们会有产品/版本分支机构/回购吗？我知道，如果分布式模型从长远来看效果更好，他们会更喜欢它，即使最初学习新工作流的痛苦很难。

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

Answer 1

基本上，您为每个产品、每个项目和每个第三方库制作一个单独的repo，然后在子repo中适当地组合它们。在你的中央服务器上，我可能会建立一个像这样的裸回购结构：

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

这样，您就可以在中央服务器上准确地获得每个回购的一份副本。您不需要为每个分支制作单独的repo，因为mercurial可以在一个存储库中保存多个分支。

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

这看起来与中央服务器不同，因为那里没有工作树，只有指向子位置的指针。