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.
- Versioning when binary AND text files are involved?
- Diffing between two entire directories/projects?
- WebDAV auto-versioning in Git or Hg or any modern VCS
- rsync exclude according to .gitignore & .hgignore & svn:ignore like --filter=:C
- Mercurial equivilent to git's HEAD~1
- How do I hide a file from a single remote repo in git?
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,
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
Root/release1/ProjectX/ Root/release1/ProjectY/ Root/release1/ThirdParty/XXX Root/release1/ThirdParty/YYY
Root/release2/ProjectX/ Root/release3/ProjectY/ Root/release2/ThirdParty/XXX Root/release2/ThirdParty/YYY
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.
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:
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.