From time to time, even in this enlightened age of software development, I run into developers that don’t use version control for their software projects. I don’t understand why. The state of software development isn’t like it was a decade ago where CVS was the only free option and all of the commercial systems cost a lot of money. I even remember when people had to pay for Visual SourceSafe just to endure the pain. But in the modern era, there are a lot of choices that are very economical, and the commercial systems aren’t that bad either.
On my personal projects, I currently use Git. I was skeptical of Git at first until I bought a book about it and started using it. So far, I love the model that a “distributed” version control system gives me. A distributed version control system differs from the classic model because there isn’t necessarily a central version control server that you publish changes to. All changes to a project happen in a local copy of the repository. What’s so great about this is that you don’t have to be online to check out files, make changes, and commit your changes. By default, the working model is that you’re working with an offline repository. When all of the changes to the repository are complete and you are ready to deliver your work, you “push” the changes to another repository. The remote repository could be on someone else’s machine, a share drive, or some service such as GitHub.
Before using Git, I was all over Subversion. Subversion works in every way that a version control system is expected to work, and the price (free) is very attractive. Subversion has achieved great integration with a lot of development systems including Visual Studio and Xcode. It also boasts the world’s best version control client in TortoiseSVN. TortoiseSVN integrates directly with Windows Explorer and uses icon overlays to show you the status of your workspace. It is truly fantastic. For integration with Visual Studio, I purchased a license for VisualSVN. There’s also an open-source add-in for Visual Studio called Ankh, but I liked VisualSVN better in comparison and the price was pretty reasonable.
In my professional life, being a consultant and evangelist for Microsoft technologies, I typically find myself using Microsoft’s Team Foundation Server. TFS is a good product and has gotten better over time. The integration with Visual Studio is fantastic. The work item support, project tracking, and reporting capabilities are superb for managing professional or commercial projects. But given that, I do have a couple of complaints about it. First, TFS is not a speed demon. It can be slow at times. Second, TFS doesn’t have a great “client” story. TFS is truly a server product. A client is provided through Visual Studio, but it can take time to work through the interface. TFS also has integration with Microsoft Excel and I’ve found it to be a superior client experience for working with task items instead of working through Visual Studio. The Excel integration is fantastic in my opinion, but others may not find it ideal to be working with TFS directly through Excel.
Back to the point of this post, why do I love version control? The number one reason why I love version control is that it lets me back up to a known point in time. On occasion, I get these eccentric ideas and start going down a path. It may be a breakthrough idea that has to be implemented, so I’ll work down that path. After a few days, and a few interruptions when the weekend is over and the work week starts again, I may stop and rethink the problem. I sometimes come to the conclusion that what I’m doing is bad, or makes the problem too complex.
Over time, I’ve come to believe in the concept of throwing code away. Not all code that I write is going to survive the test of time. I’m also a firm believer in the fact that I’m a better developer now than I was five days ago, because I’ve learned stuff over that five days such as that idea that I came up with five days ago was a bad idea. While I’m not advocating throwing out entire products, at times, small chunks of work that get written may not be the best thing for the product.
When that happens, I find that the best thing to do is go back to where you were five days ago and take a fresh look at that problem. That’s where version control comes in nicely. Using any modern version control system, it’s relatively easy to undo all of the changes that have been made since the last commit and restore your project workspace to the state it was in at the last commit. For Git, the command is:
git reset --hard
This command will take my local project and will reset the state of my staging index (the changes waiting to be committed) and my project workspace to the state that they were in at the last commit. At that point, I can move forward happily and with a clean state, but this time promising not to make the same mistakes that I made previously.