One of the 12 Steps to better code is version control. Version control is a method of keeping programmingn code backed up, essentially. It is a lot more complicated than that, as I’ll discuss, but in if you keep that in your brain it will help.
I had never used formal version control at work, but the winds of change are a blowing and a new policy is requiring all developers to use version control. When I heard we were going to have to use version control I started to read up on it. Version control is one of things I’ve read about and see referenced all the time but never really looked into it because it was always referenced as a requirement for team development. As a one-man department, I figured adding a layer would just slow me down. Silly me then thought we were moving to more collaboration with a shift to using VC. I thought wrong.
I was actually told out right by a big boss that “we are not interested in collaboration” and thus version control is really just a fancy backup system. Unfortunately, VC loses some of its shine when you take away the collaboration. One of version controls selling points is the ability to allow multiple people to work on the same project, even the same file, at the same time without getting in the way of each other.
You see, the code really lives on a separate computer in a database, called a respository – which you should try not to confuse with a suppository. This repository is the common link between developers and works similar to a public library.
Developer A uses a client program on his computer to “checkout” the program code from the respoistory. This is all logged with a date, time, and the person’s name. This checkout process copies the file from the repo to his computer, where he can then work on it all he wants. Now at the same time, Developer B can also checkout the code and work on it – either a same file or different file. Then when either developer is done, they return the code to the repository, making this new, updated code available to everyone else. And in cases where A and B were working on the same file at the same time, the version control will let them know that so they can choose which changes to merge into a single file. It sounds complicated, but is a pretty basic concept if you think about it.
Now, the cool thing about version control is the “version” part. The control lets you go back and see the state of any file at any point in the past. So if a file has been changed 26 times since last Monday, you can go back and see what that file was on Tuesday or Wednesday. Imagine if you had the history of a book you check out from the public library – where it’s been, how it was treated…kind of cool.
This is all great and well and you can see how it could help a team of people working together, but how does it help one person. Isn’t it just backup then?
That’s what I thought, and basically it is a fancy backup, but version control has one very cool concept that I have really used and has really saved my butt a few times. But lets see how it was done before.
I’m working on version 1 of a program. It’s in a folder called “Version 1” on my computer. It’s great for a while but then I need to update it. The pre-VC process would be to copy that folder to another location and rename it “Version 2”. I would make my changes there and test it, then delete the “Version 1” folder and just rename “Version 2” and everything would work.
This works but I lose the historical aspect unless I put each old version on disk before I delete it, which is quite a hassle and not always necessary so thus it rarely gets done. And inveitably, I would end up with a “Copy of Version 1” folder and “Copy of Version 1 (2)” folder as I continue to make updates and changes. The result was confusion about which code was the newest and which I really needed to keep.
The version control lets me connect a single folder on my computer with any single folder in the repository. So all the numbered versions exist in the repository, not on my computer. And there’s this handy “switch” option that lets me switch between any version in the repository within the same space on my computer.
Let’s say you have one candy dish, but a lot of types of candy. You don’t want to mix all the candy together, nor do you want to have a dish for each type of candy. Version control is like a candy dish where you put on the lid, press a button, and take off the lid to find a different type of candy each time. You can have lots of different candy available instantly, but you are constantly filling the same space over and over. No waste. It can be pretty handy.
Another good aspect even for a one-man operation is availability to others. I’m not the only one doing web development at my place, but the few of us are never working on the same project – there’s no real team – but with the repository I can have Bob download my code and review it to get his toughts and opinions. He can read it and see it, but he can’t make any changes to it. And I can do the same thing with his code. So even without project collaboration, version control opens up other avenues for group work.
The hard part with version control is not understanding it or using the software to do it, it’s fitting the process into your workflow. Adding any step to any process slows you down, you can’t beat that, but I’ve found the addition to be a minimal hassle. I’ve been using TortoiseSVN with a Subversion server and it has been working great with a relatively low learning curve.
If you’re looking at doing version control but don’t know where to start, like me, then I suggest reading through a few chapters of the free SVN book. It gives you some recommendations on the structure for your repository and the basics on how to keep things straight.
What I thought was a step I could skip because I am the “I” in “team” turns out to be one I should have listened to from the start.