Living with Subversion

| 0 Comments

It's now around a month since I started shifting the bulk of my source code from CVS to Subversion. In that time I've move most of my internal use code, and a couple of clients. I've done several client releases and developed several new features for The Server Framework on isolated development branches which have then been merged back in to the main trunk. I've also updated my continuous integration server to use the new source code repositories and, generally, just got on with it and lived with the new system.

Overall I like it; not least because the NAS that runs my SVN server is considerably less noisy than the old machine that runs my CVS server. It's nice to have one less whistle in my head. What's more it deals with backing the repository up automatically, even if it's in use at the time (mainly due to how the NAS can simply snapshot the drive and then backup from the snapshot).

Once I'd fought with the SVN way for a little while whilst trying to shoehorn my CVS style of working into it, I eventually gave in and embraced the SVN way. I used to have a complex double tag system for each release where I'd tag a 'development' system (i.e. everything I need to work on the code) and then tag a 'release' system (i.e. everything that I send to the client); this usually meant that the release tag was just like the development tag but with all the test harnesses removed. This was easy to do in CVS but hard in SVN. Now I simply tag the development state of the code and have a script that converts a development tree into a release tree; I probably should have had this all along.

Clients each get their own repositories. I like this; I've got lots of 'dead' clients in my CVS repository; people I haven't worked for in years. It will be nice to be able to archive these off to somewhere else if I need to in the future. Clients also now get their own copies of the 'shared code' that they use. In the single repository design I used to have, a client release would use CVS Modules to pull all of the pieces that it needed together. A release tag would then tag the client code and the shared code. This worked but it meant that the shared code accumulated tags from all clients ever. This always seemed like a bit of a mess. Now I physically copy the shared code into the client's repository. Merges of new shared code to a client are just the same as before, as are merges of client changes to shared code back to the shared code trunk. The only difference is the duplication of code in the repositories but this means that each client has their own, stand alone, repository which doesn't depend on anything else.

Within some of my own repositories I use 'externals' to pull in the shared code. This also works, and makes sense for The Server Framework examples (which live in their own repository). There's no sense in having these in with the shared code and there's no real sense in having the shared code in with them...

So, everything is good, but I think I may need a faster SVN server eventually, but I hope that I can then replicate from that to the NAS SVN server so that the backup strategy remains pretty much the same.

Leave a comment