Many Projects/Repositories and common Libraries
Chris.Scott at mmodal.com
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