Programming with Poise

Useful Applications: Part II

If you’re reading this post, and you’re familiar with version control software, and you’re not using it for one of your current projects, shame on you.

That having been said, for those unfamiliar with it, let me explain. Version control software is a client-server application which tracks changes in files over time. That’s it. Pretty dull, huh? It has it’s uses. When you want to start a new project, you create what’s known as a “repository” for it under the version control system. The repository keeps track of all the files you’re dealing with. If you delete a file from your project, you tell the repository that you deleted it. If you add a file to your project, you tell it that you added a file. And when you change files, you tell it which ones you changed. And that’s really all there is to it.

If this seems unnecessary, that’s understandable. It did to me at first. But there are numerous advantages to be gleaned from using version control software, such as CVS, or Subversion which is what I use. Ever have one of those dismal “oops” moments? The kind when you’re crawling around on the command line (am I the only one who still uses the CLI?) and you accidentally delete a file? Or you accidentally overwrite the wrong file? Well, them’s the breaks, I’m afraid. Unix isn’t shy. You delete a file, it’s gone. Unless you’re sitting on a nice desktop like Gnome or KDE, which has built in recycle-bin functionality, then that file is history.

Or is it?

If you’ve been using version control religiously - which I submit as the only way to use it - then all you have to do is open up your version control client application (I recommend TortoiseSVN if you’re on Windows, and RapidSVN if you’re running Linux) and revert the dirty deed from the repository. It’s that simple. There’s always the wonderful case when you find a bit of code, and you don’t know when or why it was added, and you remove it, only to find out days later it broke another section of the application. Version control will let you bring up ANY previous version of a file that you’ve committed to the repo (that’s short for repository), at the push of a button. And with a nice file comparison tool, you can easily see what you changed, and where.

A good version control client will also allow you to merge files together. Say you’re working on lines 1-40 of a file, and I’m working on lines 41-100. Well modern version control systems were built with teams in mind. You commit your changes, and I’ll commit my changes. If our code changes don’t affect one another, then the two will be accepted by the repo without complaint. If they do conflict, however, you’ll be able to see what’s different where, and easily rectify the disagreement.

If you aren’t using version control for every project, then you’re doing yourself a disservice.

As a note, I like Subversion because of it’s ease of use. Also, Tigris (who maintains Subversion) puts out both the Windows and Linux clients I mentioned, TortoiseSVN and RapidSVN, respectively. So it’s all packaged by the same great folks. And those file comparison tools I was blathering about? TortoiseSVN has one built right in. For Linux I can recommend Meld. There’s a small learning curve, just in getting used to how these systems work, and learning to discipline yourself into using them properly, but once you get it - I hate to use cliches - it really is one thing you’ll wonder just how you got by without.

For those who don’t have a server of their own, or don’t feel like tooling around with daemon services, there are free online services such as the wonderful Assembla which provide a Subversion server to you, wherever you are. All you need is a network connection.