If you’ve been doing development very long, chances are you have had at least one “OH CRAP” or maybe even it’s big brother “OH S…” moments when you realized that you’d just deleted something you can’t get back, overwrote some bit of very complex code or done some similar bone-headed thing that wound up causing you a lot of pain. Had you had a good version control system in place and operating, you’d not have needed to uttered either of those phrases.
At their most basic, version control systems are nothing more than a historical record of every change made to the files that are contained in them. Now, most modern systems have many more functions that just that, but at the core, that’s what they are designed to do–make it possible to recover historical versions of various assets.
I’ve used 3 different version control systems in my career so far–Microsoft Visual Source Safe, Concurrent Versioning System (CVS), and Subversion (SVN). By far my favorite and the one I currently use for all the projects I have control over is Subversion. There are others out there including PVCS (a real bear to work with from what I hear), Git (a fairly new entry into the space that is making a lot of heads turn with its new approach to distributed development) and probably others that I don’t know about.
I currently have my Subversion server outsources to CVSDude. I may be changing that in the near future as I was turned onto the Buildix package from ThoughtWorks that includes Subversion, Trac and CruiseControl pre-configured to work with one another. If I have time in the next couple of months, I may set up a new VPS with my VPS host and dedicate it to SVN/Trac/CruiseControl duties.
I won’t go into all the features that Subversion offers here. Suffice it to say that it is robust enough to be used by teams of several hundred developers that interact with massive code bases. However, it’s not just for the “big guys”. Even a single developer can see real benefit from it not only as “OH CRAP” protection but as a means to track build versions and provide a synchronization mechanism for those folks that work across more than one computer–and that’s just to name 2 things off the top of my head.
I made the decision a while ago that I wasn’t going to work on any projects that weren’t housed in Subversion in some fashion. If the client doesn’t have their own in-house SVN server, I create a project on mine. I’ve learned the hard way that it’s better to use my own server resources than to do something stupid and lose hours or days worth of work with no way to undo my mistakes.
As I discussed in my last post, my Subversion client of choice at the moment is Subclipse which is a plugin to the Eclipse framework. I really like having the ability to right click a file, folder or entire project and find the commands for interacting with the SVN repository right there, without ever having to leave the program I use to create my code.