mercurial use case solution

Question

Hi,

the project that i am involved in has a lot of small modules that are managed by different developers.We are currently using svn but wanting to switch to mercurial,as we need to go to client site and do a little bit of development and so it becomes difficult to manage versions..

But the complete trunk is huge about 4-5 GB and creating a single repo for all the modules mean that if i ever need to bundle the repo i need to move this 4-5 Gigs of file.. and i cant take a backup of the smaller modules(as they dont have .hg folder) that are within one base folder where the .hg folder exists,as it would not give me any way of comitting from the backed up module(folder).. so whats the best way to deal in such a situation where one project has many modules and say... all developers take there own individual modules(keeping size of data to be transfered to minimum) with them, code wherever they want and then bring it back and merge their branch.

one obvious soln that comes into my mind is that every module becomes a repo but that would be difficult to manage specially when one integrated product will be released..what version would that release refer to?? as all modules would be having there own version history??

and a more obvious case would be if i convert the complete svn history into mercurial..then that conversion if done on trunk,it would make a single repo but with huge size..and every module owner taking this huge bundle with him everytime would be meaningless..

So any suggestions??

Thanks.

Answer 1

Tonfa says it in a comment, but I'll put it out there as an answer: Use Mercurial's Submodule Support. It says expirimental, but it's made it through months of the 1.3 release w/o a major bug or change, so I suspect it's into the zone where any upcoming changes will be backward compatible.

Also, if you have some very big files (> 10MB) puffing up the repo you can use the Big Files Extension to move them out of direct control, but still track their version.

In general, though, I find that if I make my build scripts sufficiently comprehensive that they download big, non-hand-edited assets instead of putting them in source control, repos don't tend to grow to 4 or 5 GB -- that's a lot of KLoC. Maybe this migration is a good time to use a dependency downloading tool like Ivy or whatever is suitable for your development environment.

Answer 2

On web sites we put everything except MP3 and FLV files under mercurial and we rarely get over 300MB. Besides, disk is cheap. If you have bandwidth issues between you and the customer site (or some sort of security concerns) you might want to just clone the whole tree onto a thumb drive, go to the customer site and hack, then come home and the merge changes.

Mercurial has fundamentally changed the way I look at version control. Stuff like this used to be a big deal and now ... eh.