On Wed, Oct 13, 2010 at 12:05 PM, Mauro Adolfo San Martin Ramas
> However, now I need to set up a repository for a project composed by several
> modules where different subprojects (comprised by subsets of modules) need
> to be compiled and tested independently. Usually each team is actively
> developing only one module but requires the latest (or stable) versions of
> some of the others to build and test.
I notice that each project only develops one module, but "uses"
several other modules. What does it use from those modules? Does it
need the source code? Does it need some sort of built object (like a
DLL, a shared library, or JARFILE?) Can you version the dependent
Let's say this is a Java project, and all the dependent projects build
JAR files that you need for the project under development.
I would version the subprojects the best you can, and I would store
these dependent jars in a Maven repository such as Artifactory or
Nexus. Then I would use either Maven or Ant/Ivy to pull out the
prebuilt jarfiles into the project I'm developing. This will make it
easier to say I'm developing Project "A", and it depends upon version
1.2 of Sub-project "B", version 1.4 of sub-project "C" and version 1.1
of Sub-project "E",
Maven repositories are great even if you don't have a Maven project.
They enforce the concept of version and type and give you easy access
to the object. Ant with the Ivy addition has no problems with them.
Maven, of course, uses them with aplomb. I haven't seen any case of C
and C++ projects using Maven repositories, but I really can't see a
reason why not.
This way, you avoid putting built objects under version control, and
usually in the end, you end up with a better understanding of what is
in that third-party product than if you committed a particular version
in your repository. I've seen a lot of Ant projects were foo.jar was
put into a project, but after a few years, no one knows what version
of foo.jar was in there. Maven and Ant/Ivy eliminates this issue.
If you're sharing source code, you can try to use the svn:externals
property. However, you have to learn to maintain it.For example, if I
have the svn:externals property set to the trunk of a sub-project, and
I tag the project, the tag points to the latest version on trunk of
that sub-project and not to a stable version (which a tag is suppose
to point to!).
Most people point externals to a sub-project's branch while
development is taking place on that sub-project and then to a tag on
that sub-project once you release the project or the sub-project
stabilizes. This means someone hast to track these svn:externals
Received on 2010-10-13 19:20:51 CEST