managing vendor code with subversion

Thu, Oct 30, 2008

We’re using Elgg as the basis for building the UHI Communities network and as we’re doing quite a lot of customisations of the core code, we need a way to manage Elgg releases and how they get merged into the communities code. The requirements are simple. All source code must be under version control. There are other ways to manage vendor code that don’t version the actual source code but I did a bit of research and found the ideal solution. The Third Party Codeline SCM pattern. I initially got the basics from the superb Pragmatic Version Control using Subversion and there’s another summary here and an article here. As ever, a picture is worth a thousand words:

The basic idea is you start with an empty project and import the base version of Elgg that you’re going to start from. In this case, I’ve taken it from elgg-0.9.1, to show how to update to the next release. Import 0.9.1 and tag it as 0.9.1 then construct a /trunk directory from the 0.9.1 tagged source. We’ve now created our mainline. We’ll develop in there, adding UHI Communities customisations and committing all source code to svn.

After a while Elgg release 0.9.2 and we want to upgrade. Doing this manually is rather difficult but we can use the svn tool, which you can get from here. This commandline tool takes care of all changes between 0.9.1 and 0.9.2 in our repository. We then merge those two versions into our mainline, resolve any conflicts caused by UHI modifications, commit our mainline changes and continue developing.

That’s Third Party Codeline. Now we want to make a release of the communities application.

We create a 1.0 release branch from the mainline and start doing integration tests etc. Once we’re satisfied with the result, we merge any changes from the release branch back into the mainline. We then tag the release branch and that tag becomes the repeatable release of UHI Communities 1.0.

We can then continue to work in the mainline, starting from Elgg 0.9.2/Communities 1.0 as a base. When 0.9.3 comes out, we just use to make another vendor drop, merge the changes between 0.9.2 and 0.9.3 into our mainline, resolve, commit and continue.

Here are the steps I used to verify this actually works:

comments powered by Disqus