Ideas for handling "virtual" projects in source control?

July 18, 2008 6:35 AM

What are some good ways of treating an arbitrary group of related projects in a source control system as a single project? CVS has ampersand modules, Subversion has externals, but they're both flawed. I'm looking for workarounds, alternatives or ideas I have not thought of before.

I am working on a project in which certain parts of the codebase (plugins) are shared between different, but typically related, applications.

We want to be able to create a "virtual" project in source control which simply consists of pointers to other subprojects in the same source control system. That is, we want a developer to be able to check out project_a which contains no source; simply pointers to subprojects like project_b/somedirectory, project_b/otherdirectory and project_c/differentdirectory. Updates, commits, tagging and branching on project_a should apply to all the subprojects to which project_a points. Tagging a virtual project should allow us to check out exactly the same thing at any time in the future, even if the list of subprojects changes on the trunk.

CVS ampersand modules almost gives us what we need, but it's my understanding the file defining the subprojects is itself not versioned, so there is no way to reliably check out a historical version based on a branch or tag. Likewise, subversion has svn:externals, but committing or tagging at the root of the checked-out project does not apparently descend into subprojects.

I currently deal with this by having a project with an Ant script which itself checks out the subprojects from various subprojects. It is simple and it works, but it makes tagging, branching and automated builds harder than they ought to be.

If anyone else has better ideas of how to solve this, I'd love to hear about it.

posted by tomwheeler to Computers & Internet (3 answers total)

This is one area where Perforce shines. You can put all of your projects into your Perforce depot, then individual developers can check out "views" of the depot that include arbitrary subtrees, in any layout you need. Commits and tags work across all subtrees. Branching in Perforce is a bit different (more flexible) than CVS or Subversion, and you may need to script it to get the sort of cross-package branching that you want. The "views" themselves are not versioned, but again this is something you can script. (We did something like that at a previous workplace.)
posted by mbrubeck at 6:56 AM on July 18, 2008

svn:externals are properties of the directory that get recorded when copied (tagged). svn doesn't follow the external links when copying; externals can point anywhere (another repository, a specific version, etc). After I branch or tag, I go back in and edit the svn:externals to point into the new branch, and check it back in. Mildly tedious.

Subversion 1.5 adds relative svn:externals, so if your externals are elsewhere on the same trunk, if you copy the whole trunk, the svn:externals will also be versioned, because they'll be relative to the new directory copy.
posted by and for no one at 10:16 AM on July 18, 2008

Recent versions of git (say, 1.5.3 or newer) have support for submodules. I think this will do what you want in that your virtual project_a stores pointers into revisions of each subproject, and those pointers are versioned.
posted by Rhomboid at 12:19 AM on July 19, 2008