This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it.

A long long time ago, in the dim and distant past, revision control consisted entirely of making a tarball of your code tree from time to time and calling that "releases". We passed from there to "local" revision control such as RCS and SCCS and from there to ways to collaborate with tools like CVS and thence to SVN, TLA, BZR, git etc.

If you'd like to know more about revision control, Lars wrote a very good article on the topic.

When I started writing open source code seriously, waaaay back in the dim and distant past, I used the tarball method (although they were zip files because I was stuck on Windows in those days since Linux hadn't really gained enough popular traction to work on my computer). The best way to "push" to that kind of revision control was to put it up on a website and persuade others to download it -- that way when your hard drive broke you could re-download it and not lose too much work. Since then, with CVS, SVN, etc I would have a server online somewhere and push my code to that. Said server was also backed up, but even if it hadn't been I'd have had two copies of my code.

It's possible, even now, for me to look back at some of the code I wrote a long long time ago (and cringe) thanks to conversions of those revision control repositories over time. And this is one advantage to having pushed the code -- it does still exist. From time to time I'm amused enough by something old to rewrite it in a modern way. For example the time I played with my countdown program (originally written in Pocket-C for PalmOS) and then ended up making a bad Haskell rewrite which didn't quite work, but was fun. That replacement is also pushed to revision control -- I wonder if any of you can find it and fix my bugs?

Keeping older versions of code can also be instructive. I'm very glad for the revision history for my Gitano software (mentioned in truism 2) because I can look back at different ways I did things and remember why things are the way they are now. This holds true for so many projects I'm part of that I sometimes wonder how I coped before I kept everything in revision control.

There are days when I am sad that some of my very early work is no longer available to me because it only ever existed on floppy discs which I can no longer access, even if I knew where they were. I'm hopeful that one day I'll clear a box in a house somewhere and find them all again and have a joyful time doing data archaeology. I'd love to find the statistical analysis of the random number generator I wrote for my Dad's computer back when I was 5 years old.

However, enough reminiscing. I am only trying to illustrate the point that if you have not kept your code in revision control then you miss out on so much that revision control provides, but that more importantly, if you have not pushed that revision controlled content elsewhere in some manner then you lose out just as much because data is fragile.

Your homework this time depends on your attitude to revision control. If you subscribe to this approach already then you should go find something you wrote a while ago and browse the code and the revision history and have a lovely time reminiscing over your past self and how clever/stupid they were. If you do not currently subscribe to this approach then your homework is to go find something you wrote which you're very proud of and love to bits, and then imagine how you'd feel if you lost it forever. Then you can put it under revision control and push it somewhere for everyone else to admire.