DVCS how structure with large integrated code base, with multiple projects sharing much common code?

I have a cvs repository, with mostly java code. Each package sits in it's own top level dir, like so, with the sourced laid out in typical java fashion.

$CVSROOT/my.domain.module1/src/my/domain/module1
$CVSROOT/my.domain.module2/src/my.domain/module2
$CVSROOT/my.domain.share1/src/my/domain/share1

This means we can write build scripts that can easily pull any combination of packages out of the repository in order to build a particular shippable piece of software.

So if I checked out my.domain.module1 the build script in that module will then pull in my.domain.share1 as well. This re开发者_C百科ally promotes code resuse.

The approach has strengths and weaknesses - not really interested in that today - just given this type of approach is it possible/sensible to replicate in mercurial or git.

From what I can tell you'd need to either define a whole repository per package, or checkout and commit the whole repository each time!

Regarding DVCS in general, a repo per component is the right size. Since they have the all history for their respective components, having only one repo for any component out there would not scale well.

Git will use submodules, Mercurial Hg will use subrepos.

The idea is to define a super-project (a repo in its own right) which will:

• have its own files
• have some of its own sub-directories being to root directory of a submodule components for a given reference (SHA1, tag, label)

If you do some modification from the main project directly in one of those sub-components, you must first commit those subrepos, and then go up in your main project to commit that main project (it won't contains all the data, only its own data, and some pointer to the new submodules references you just committed before)

It sounds like you have a great setup for using ivy. It lets your build system handle the pulldown and compile-against parts of your dependencies, and the source control just tracks point-in-time for modules.

Then in your ivy dependency files you have a clear record of what version of each component the others depended on and can revert/advance easily.

You could also use mercurial sub-repos, but I prefer using a good dependency manager like ivy.