Software releases 1: svn structure¶

Tags: python, django, softwarereleasesseries

Software releases: when you want reliable software, you’ve got to have some infrastructure in place. And you’ve got to work in certain ways: good habits. Over a course of (estimated: 6) articles, I’ll show you what to do and what to set up if you start from basically nothing.

First things first: you’ll need to have all your code (and website configurations, and…) in a version control system. I’m assuming subversion (“svn”) here.

But don’t put your project’s code directly in an svn directory named after your project. In that case, you have one location that you use for:

• Current ongoing development.
• Experiments. But you probably don’t commit those and instead keep them locally in an uncommitted change because you don’t want to pester your colleages. If you do commit them, you’ve earned the 220V wiring they installed in your chair.
• Making checkouts on your live servers. You might do an “svn -r1234” checkout with a revision number in there, but an “svn up” wipes out that knowledge and updated to the most recent version.

Solution: a trunk/tags/branches structure. There’s a subversion convention for setting up your repository. It is a bit of extra bookkeeping, but it is necessary bookkeeping. Inside your project_name directory you need a tags, branches and trunk directory. Something like:

The purpose of the various directories:

• Trunk: current development. Trunk should be in a workable state all the time, otherwise you’re blocking colleagues. So normally all tests ought to run just fine before your commit. Doing a couple of commits within 15 minutes with intermediary commits breaking is normally fine (warn your colleages), but if you leave the trunk broken for weeks you ought to be whipped.
• Branches: maintenance branches or experimental branches or long-lasting changes. If your changes would disrupt trunk too much, create a branch and do your work there in isolation and merge back when finished. And if a customer wants a bugfix for an older release, make a branch off that release, make the fixes and push out a x.x.1 release. And if you just want to try out a few things: branch also. Name the branch like “yourname-purpose_of_the_branch” (for instance “reinout-adding_script_support”) so that it is clear what the branch is for.
• Tags: every release should be tagged. A tag is simply an svn copy. So svn cp http://yourproject/trunk http://yourproject/tags/0.1. The idea is that you can get a reliably fixed snapshot-in-time. It beats the pants off “svn up -r1234”. And you can make a release of your python project (zest.releaser-1.2.tar.gz) which will be easy to identify in your svn (zest.releaser/tags/1.2). You can even generate releases automatically from such a structure.

The exact behavioural rules vary a bit from project to project, especially in how strict you are in creating new branches compared to working on trunk.

Summary: the basis of proper releases is a good svn structure with trunk/tags/branches per project.