Repository layouts

Once Intrepid comes out on Thursday we'll be able to upgrade one of our newest publicly accessible servers to it. Why does this matter? Because Intrepid has Subversion 1.5 we will be able to move our repository to that server, and that in turn means that we'll be able to open up the repository to a wider audience. We have some things that hopefully will be interesting to others, but this also means that the question of repository layout comes up (yet again).

We have a single repository that we use for everything. This has advantages and disadvantages. One of the advantages though has to do with the standard layout of repositories, and that's what I wanted to write about now. At the very top level we have public and private areas, an external area where we link to and mirror external dependencies that we use. Finally there is a partners area

For the actual part of the repository that have software projects most sources say you should split a repository out into three parts:

• trunk — main development.
• branches — work areas.
• tags — released versions.

The problem that I have with this is the last. It's just not very useful (and I'm always forgetting to tag releases, tests and everything else I ought to be tagging). After all, you can always get to any version by just having a revision number — and as we have a single repository then a single revision number is all you need to uniquely identify a release of any of our software.

Mostly we're going to be open sourcing our library code so the use of the code is mostly of interest to ourselves and other developers. What I'm going to try out instead is the following layout:

• trunk — where we do our main development. This will operate under a semi-stable system. Bug fixes will normally be done straight into trunk and test releases will be done from trunk.
• branches — where new functionality is built. I expect that we will be very liberal about giving commit rights on new branches to people who ask.
• stable — the latest stable release of the library.

What this means is that if you want to take the new upcoming Fost 4 libraries (the upcoming Linux/Windows port of FOST.3™) then you will normally want to develop against stable. You can do this very simply by using Subversion's svn:externals feature. When we release a new version it will always have the same repository location so it will always be easy to find. If you want to use a particular version then you can still svn:externals, but specify the revision number of the release that you wish to use.

I'm hoping that this will be a bit easier for us and for future users of our libraries (even if those users only ever turn out to be us).