Many Projects/Repositories and common Libraries

Chris Scott Chris.Scott at
Mon Jan 10 14:51:50 CST 2011

> As a new user, I have read that it is best to place
> each project into its own repository.  

True.  Personally, I think it's easier to manage change-sets when repositories are limited to one project.  Otherwise, you'll see a ton of merges for stuff that doesn't affect each other and doing code reviews gets very cumbersome.

> However, I also have a common
> library/API that is used by a number of those projects.  I want to use
> the library at a version level and be able to replace/update the
> library in any project at any time.  Is it still best to keep
> individual repositories and then copy the library into the directory
> of the project as it changes?

I wouldn't copy the whole hg repo over, but this is a common use-case.  

You should use an artifact/dependency management system instead of shoe-horning this into hg.  If you're using maven, you're halfway there but need to buy into "The Maven Way".  I like apache's ivy because it gives us finer grained control.

Basically, ivy would publish your API builds to an artifact repository.  Then downstream projects can specify the published build as a dependency and it will automatically retrieve the resources (jars, dlls, headers whatever) for the build process.  You can either specify that it use the latest version, latest stable version, or a specific version; whatever you want.

Combine ivy/ant with a continuous integration tool like hudson that builds on each commit, and you're light-years ahead of what you'd be able to do with just copying repositories around.


More information about the Mercurial mailing list