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

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.

  • Mercurial — revert back to old version and continue from there
  • Change Git Parent Branch
  • How do I properly branch post-commit and revert the trunk in svn?
  • git-svn: how to create a tag/branch for a sub project of SVN
  • Git - Branching and a shared code base
  • Git commits are duplicated in the same branch after doing a rebase
  • 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/ThirdParty/XXX -- could be a 3rd party lib
    Root/dev/ThirdParty/YYY -- could be a 3rd party lib

    (branch 1)


    (branch 2)



    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 and a number of articles but I’m still unsure as to how to organise.

  • Is conditional branching a requirement of Turing-completeness?
  • Is cross-branch reference possible?
  • Find first common child of two commits
  • Would you migrate from cvs to svn or directly to git or hg?
  • How do I update my forked repo using SourceTree?
  • Can we finally move to DVCS in Corporate Software? Is SVN still a 'must have' for development?
  • One Solution collect form web for “Mercurial: Granular Repositories Vs large Repositories and shared third party tools in version control”

    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:


    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:


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

    Git Baby is a git and github fan, let's start git clone.