What to do with multiple projects depending on the same source?

Question

This is something I\'ve come across twice in the past month and I\'m not even certain how to phrase this as a Google query.

I\'m actually using SVN for all of this,

Answer 1

We've used svn:externals pointing to shared code in practice for a few years now. We have had some interesting problems with it that you should probably consider before using it though. Here is the structure that we have:

root
+---common
|   +---lib1
|   |   \---trunk
|   |       +---include
|   |       \---src
|   \---lib2
|       \---trunk
|           +---include
|           \---src
+---proj1
|   \---trunk
|       +---include
|       |   \---common
|       \---src
|           \---common
\---proj2
    \---trunk
        +---include
        |   \---common
        \---src
            \---common

The common directories in both include and src in a project contain external definitions that pull in the common libraries:

c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
  svn:externals : lib1 http://.../common/lib1/trunk/src
                  lib2 http://.../common/lib2/trunk/src

The problem that we've run into is multifaceted but related to tagging and branching our source as the projects change throughout time. The externals definition that I showed above has a few pretty severe problems if you want to have reproducible builds:

1. It refers to a dynamic target - trunk.
2. It doesn't refer to an explicit revision.

When you branch using svn copy, the externals are copied verbatim since they are really just properties attached to the object. Some of the other svn commands (commit, checkout, and export) actually interpret the properties. When you tag a project, you really want to preserve the state of the project for all time. This means that you have to "pin" the externals to a specific revision so you need to change the externals definition to explicit refer to the revision that you want (e.g., "lib1 -r42 http://.../common/lib1/trunk/src"). This solves one facet of the problem.

If you have to maintain multiple incompatible branches of the common code, then you have to specify which branch you want explicitly along with (possibly) the revision.

Needless to say, this can be a bit of a headache. Luckily someone out there in Subversion land write the svncopy.pl script that automates some of this mess. We are still (and have been) struggling with some of the difficulties supporting this in a field deployed product with a bunch of shared code and a mandate of three different versions in the field at any time.

If you do go down this route, then be sure to consider how you will maintain the linkages as the projects grow and change. We've found that a little bit of time thinking about a process will go a long way here.