Note: I wrote this in 2005 – it was originally based on an email to a friend. I was surprised to find the software development team that he was part of worked on complex code, collaborating by emailing source files to each other. They thought setting up a CVS server was too much effort. I would be surprised to find teams working like that today, but I was surprised then too. It’s 2014 now - use Git.

If you are writing software to last, and doing it without revision control, you are either; (A) working slower than you should be, (B) writing buggy code, or (C) Donald Knuth.

If you’ve heard this many times before, know all of the ways you would benefit, but just think it’s too complicated, difficult or expensive to set up, don’t stop reading yet; skip to the description of TortoiseSVN below.

A Very Quick Definition of Source Code Control

A source code control system (SCCS), as you would expect, stores your source code. It might store only the code for a single project, or all of your projects in separate directories. It can usefully store one file, or thousands.

After editing your code (fixing a bug, adding a function), if it is under source code control, you then check it in to the SCCS, which now stores the latest version. And if you continue in that fashion, excluding backups, that’s all there is to it.

The benefits come the first time you break something. Maybe it’s as simple as having deleted

You might be trying to mimic some of the benefits of SCCS by keeping periodic backups of some/all of your source code. You’ll be able to spot this if your source code directory contains files named:

  • main_bak05072006_02.c
  • main_new.c
  • main_working_tues_thanks_jeff.c

You might laugh, but those files, whose names have been slightly altered to protect the guilty, are all available on the Web for download in source code packages today.

So, since Jeff helped you fix that bug, something has been broken. But that was a month ago now and the file has changed in 100 places, and you’ve made changes to half a dozen other files that the calculation depends on, too. The bug could be anywhere, and all you know it that the calculation worked when you checked it last week.

You can undo (or revert in the parlance of SCCS), all of the changes to all of your files since last Tuesday with the click of a button. Or you can view the changes line-by-line and choose which to keep.

TortoiseSVN, and an ABC of SCCS

The system I describe uses TortoiseSVN on MS Windows, because it is perfect for a single-developer setup, and fantastically easy. It probably also describes the majority of those working without revision control; *nixers tend to know how to set up such a system (even if they don’t actually do it), and if you’re working in a team without revision control, then it is far beyond my power to help you.

TortoiseSVN is actually a frontend to Subversion, a powerful SCCS. However, it can be used as a stand-alone source code repository, which means a trivial installation process, easy setup of the repository and you could be storing your code in it within ten minutes.

Revision Control for Your Files in Ten Minutes Flat

  • Backup your work (really - you’ll be deleting things in a minute)
  • Download and install TortoiseSVN
  • Right click on an empty folder and use the new Tortoise menu to “create [a new] repository here”. Choose fsfs.
  • Delete all of the non-source files from your working folders (I told you). ‘Source’ here means anything that isn’t generated from other files in your working folders. Delete object files, keep the .cpp source files. Delete pdfs, keep their TeX sources. If in doubt, don’t delete it.
  • Create a new working folder. Right click and “SVN checkout” from URL “file:///C:/path/to/repository/folder/created/above”
  • Copy all of the old working folders from above into the new working folder, use the menu again to add files to the repository *That’s it. Now when you make changes in the working folder, the tortoise menu will give you many choices, although you’ll probably mostly be checking in and reverting.

Of course, there’s lots more. The repository you’ve created can be shared with others, moved easily onto a server, accessed remotely and browsed via the web, or it can serve as the centre of a development website. Read the documentation.

And you don’t need to store only program listings in there. This page’s source is stored in Subversion (erm, no longer true - it’s in Git now), so when I want to retrieve the deft metaphor I removed from the final paragraph, I’ll not be left with my cheese in the wind. I also store config files, TeX and Metapost sources in my repository. You can also store binary files, although some of the advantages of revision control aren’t relevant for them.