Mercurial: Granular Repositories Vs large Repositories and shared third party tools in version control

问题

Scenario: Various products made up combinations of the smaller projects. A few different versions of each product in dev, release and maintennace (bugs/patches/minor releases).

Most the the team use various third party tools and libraries for dev and for release (common two are XUnit for dev, and AutoMapper in product). They're fans of version controlling these tools/libraries where it makes sense.

I cannot seem understand the best way to organise the structure in mercurial. In the the central SVN style, I'd organise by having the the third party tools as their own projects and then having small builds for the projects that would grab the output of the other projects, and then a release project that would be built from the built projects. All would be in a hierarchy,

(dev branch)

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

(branch 1)

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

(branch 2)

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

etc.

Here comes the rub, due to the way that developers keep their machines upto date (using NUGET package manager) the third party items all have to be in the ThirdParty folder to to ensure that the devs don't have to have multiple copies of these libraries for each project.

My question is this:

If they implement mercurial should implement a simmilar strategy (big repo) and clone/branch here or should they break up the repository say at the project level and clone/branch these. In the latter case would they have a product/version branch/repo? I know they'd prefer a distributed model if it works better in the long term, even if the pain of learning a new workflow is hard initially.

I've read http://nvie.com/posts/a-successful-git-branching-model/ and a number of articles but I'm still unsure as to how to organise.

回答1:

Basically, you make a separate repo for each product, each project, and each third-party library, and then you combine them as appropriate in subrepositories. On your central server (or servers), I would probably set up a structure of bare repos like this:

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

This way you have exactly one copy of each repo on your central server. You don't need to make separate repos for each branch, because mercurial can hold multiple branches in one repository.

Then, when someone checks out a Product in their local repository, you use the subrepo mechanism to also check out the working trees for the appropriate projects and third party libraries. On your local disk, the structure will look like this:

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

This looks different than on the central server because there you don't have working trees, only pointers into the subrepos.

来源：https://stackoverflow.com/questions/7077439/mercurial-granular-repositories-vs-large-repositories-and-shared-third-party-t

标签

mercurial

code-organization

branch