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

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

Answer 1

基本上，您为每个产品、每个项目和每个第三方库创建一个单独的存储库，然后在 subrepositories 中适本地组合它们。 .在您的中央服务器(或多个服务器)上，我可能会像这样设置裸仓库结构:

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

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

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

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