Question

方案：各种产品组成了较小的项目组合。 dev，release和maintennace中的每个产品的几个不同版本（错误/补丁/次要版本）。

大多数团队使用各种第三方工具和库来开发和发布（常见的两个是XUnit for dev，以及AutoMapper in product）。他们是控制这些工具/库的版本的粉丝。

我似乎无法理解在mercurial中组织结构的最佳方法。在中央SVN风格中，我通过将第三方工具作为他们自己的项目进行组织，然后为可以获取其他项目的输出的项目创建小型构建，然后通过构建的发布项目来构建建成的项目。一切都在层次结构中，

（dev分支）

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策略（大型repo）和clone / branch，或者他们应该在项目级别分解存储库并克隆/分支这些。在后一种情况下，他们会有产品/版本分支/回购？我知道如果长期工作效果更好，他们更喜欢分布式模型，即使最初学习新工作流程的难度很大。

我读过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的副本。您不需要为每个分支创建单独的repos，因为mercurial可以在一个存储库中保存多个分支。

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

这看起来与中央服务器不同，因为你没有工作树，只有指针进入子目录。

Mercurial：Granular Repositories Vs大型存储库和版本控制中的共享第三方工具

1 个答案: