Three Version Control and Subversion Myths

January 26, 2009

I've learned a lot as a developer over the years. As time goes on, I learn new techniques that help me to write better code more efficiently. One of the big steps along that journey occurred when I learned how and why to use version control. I ignored version control for a long time because I fell prey to a few myths that I think a lot of other developers run into.

Version Control is software specially designed to manage multiple revisions of the documents you are working. In a programming context, this typically refers to the source-code files you create. Version control software can also help with combining changes from several developers working on the same project.

MYTH: Version Control is hard

I made my first attempt at using version control when I was working as an ASP.NET developer. It was a Microsoft world for me. At the time, Microsoft's Team Foundation Server was THE version control system for developers. I spent the better part of two days trying to set up the server, set up Visual Studio, and get the existing web site into the system. It didn't happen.

Part of the problem was that I was using the wrong tool for the job. Team Foundation Server is a large project management tool. Version control is just one part of the whole big package. I didn't know that there were other options for version control that were more lightweight and easier to get up and running. Working with TFS gave me the false impression that version control was too hard to be useful.

What I failed to see was that NOT using version control was much, much harder. Making major changes was always a tentative process. If, for example, the login page was being rewritten with some new features and a bug was found, there was no way to fix the bug and deploy the new features separately.

Version control systems handle situations like that easily. Branching a project, making changes, and merging the changes back in is just part of the normal workflow.

MYTH: Version Control is only for two or more people

For a long time, I ignored version control systems because I was working as the sole developer on various projects. I mistakenly thought that the only major benefit of using version control was to allow multiple developers to work on the same code. Checkout, check in, file locks—it all seemed unnecessary when I was  the only one who would ever touch the code.

What I didn't know, was that source control provides many benefits that even a single developer can take advantage of. Source control gives you a history of the entire development of a project and it provides it in an easily accessed format.

Source control allows you to branch a project into multiple development paths and then merge changes back together. You can work on a major new feature in one branch while continually fixing bugs in another branch. The source control tools then help you to combine those changes back together.

Source control makes it easy to move a project from one machine to another and work remotely. Want to take your laptop on a trip and get some work done? You can often check out everything you need with a single command.

MYTH: Version Control is only useful for Version Control.

I saw version control as a one trick pony specifically suited to managing source code files. However, the flexibility of version control systems allow them to be used for other tasks as well. As alluded to before, your source control repository can serve as a comprehensive backup of your entire development history. Any individual workstation can suffer data loss. Restoring the project is as easy as checking it out from the repository.

Version control can be useful for deploying projects as well. Version control systems typically support scripting making it a snap to incorporate them into an automated deployment process.

Resources:
• The next step, a more in depth look at using version control,
• Get Subversion,
• Get git