In my last posting, I talked about the benefits of code reuse and how any good programmer should swear by that coding principle.  Today, I move on to another key programming methodology, that of version control.

Version control (revision control, source control, or any of a number of other similar names) is a method for archiving and documenting changes to programming code, web pages, XML files, and, frankly, any other type of file of which you might want to store multiple versions in one centralized location.  A benefit of this is that multiple programmers can work on the same code base without interfering with each other, and that you can easily track or back out changes to a file and go back to an earlier version, should a new change cause problems.

This is something that has been hit or miss at the jobs I’ve worked at.  My first position at a larger software vendor company had a version control system for their main programming code base, but any custom tweaking that we did for clients was not included.  The smaller organizations that I’ve worked at since then haven’t had an official version control process either.  So, this is always something that I’ve been clamoring for, but I don’t have years of experience with it to list out my own version control best practices.

I’ve resorted to tactics like manually backing up my code to a new folder for each change, to installing the single-user version of Perforce onto my computer.  Neither of these would work in a large team setting, though in my recent jobs, where I worked on applications largely on my own, they sufficed.  Using Perforce on your own, however, is a terrific solution if you are a single-person company.

Getting back to the core concept of version control, it’s absolutely necessary to avoid situations where a change adversely affects an application and you need to back it out.  If you can’t readily restore to an old version of your application in case of emergency, then you better start working on setting up such a system.  The idea of Disaster Recovery in IT departments usually refers to how to get your organization back up and running should the worst happens, but version control is very much a disaster recovery system in itself.

Here are some of the more common software packages for version control, if you’d like to learn more:

• CVS
• Git
• Perforce
• Subversion
• Visual Studio Team Foundation Server

Feel free to share your experiences working with or implementing various version control solutions.  I’d love to hear about them.  Coming up next: unit testing!