Subversion and dependencies

Question

I am trying to find a viable strategy to a following problem.

We have several web projects which are dependent on our framework. Everything is stored in our SVN and has its own project with all the necessary directory structure (trunk, tags, branches). In an example - we have projects webprj01 and webprj02 and we have a framework frm01. All of those have usual SVN project structure - trunk, tags, branches.

webprj01 and webprj01 are both dependent on frm01 and in real life frm01 is present as subdirectory of webprj01 and webprj02. To achieve this in SVN it is possible to set svn:external property and we can set frm01 to point to /frm01/trunk inside trunk of webprj01 and webprj02.

To do a real life coding we have to have all three projects checked out as a working copy and do the changes to particular codebase in it's own working copy. There is no way to publish changes from webprj01/frm01 to the SVN. The change needs to be done in frm01 working copy and transfered through SVN to webprj01/frm01 and webprj02/frm01 working copies.

This solution has a problem with dependencies while branching. I make a production branche from SVN /webprj01/trunk to /webprj01/branches/release-1.0.0. In two days while working on second project webprj02 and frm01 I am no longer able to have stable checkout as through svn:externals in branch release-1.0.0. directory frm01 already points to new changes of frm01/trunk.

Described is just a simplified version of the problem. In our real life situations the dependencies go sometimes five levels deep. I'd like to be able to obtain stable code from SVN at any time. In different words. When I branched/tagged webprj01 as release-1.0.0. I want to get stable code for that particular tag in a year from creation.

It is obvious, that described strategy using svn:externals does not do the work. What would be your experience with this situation? It is not necessary to use one checkout. Even using of build scripts or other solution would be of help here. I am looking for a long time solution to the issue which would not depend heavily on human actions as we are prone to mistakes.

Answer 1

In the Java world, I would not try to solve this using only a version control system - I would instead use a dependency management tool like Maven + a version control system.

At the place where I work, we have a set-up which seems pretty common:

Any "framework" project lives in it's own directory structure (trunk, tags, branches) like you already seem to have. These are also managed using Maven and whenever something is checked in, a new version of the component (in most cases a JAR-file) is published to our local Maven repositry (which resides on a Nexus server).

Any project which needs to use the "framework" project will have a dependency towards a specific version of the framework project - Maven then automatically pulls this version from the Nexus server whenever the project is being built.

This enables us to release each project and framework component separately, but still keep track of the dependencies between them. We can even have multiple version of the framework components used by different projects without completely losing track of the dependencies.

So far this has worked pretty well for us - I can only see two drawbacks:

It takes a while to set-up, especially if you have not used Maven before.

There is some overhead when releasing each project, since you want to release each dependent component as well, to avoid having dependencies towards the "trunk" version of other components (i.e. the "SNAPSHOT" version in Maven terminology).