It continually surprises me, so much so I think it is a hoax, but I keep hearing about companies that don’t use version control (also called revision control)
What’s version control, and why do you need it?
So you write the perfect piece of code. It can display Lolcats on the screen. Everything is going perfect. You are thinking of starting a company to capitalise on your code. You know there is a huge demand for this feature, and venture capitalists are just dying for someone to target this valuable market.
So you write your code, and then get busy with other things. The latest Y-Box is out, and you need to catch up on your gaming. You
waste gainfully spend a whole week finishing Battle of Nerds 3. And then you get back to your multimillion idea. It’s almost complete, you just need to change a few icons on the screen, add a few fancy buttons. And then, you are set for life.
You make the changes, and (drums rolling … ) nothing works. The whole thing falls apart. You press Ctrl Z (undo) many times to remove all your changes, but the code still isn’t working. In panic, you scream. Why isn’t it working! It was working just a week ago. You can see your dreams of sitting on piles of cash go up in smoke. Why does this always happen to you?
Think this is bad? Now imagine ten people working on your code, living in different parts of the world. They are all changing the code, and breaking it. You’ll never get your LolCats masterpiece to work!
How I discovered version control
My first job was at a startup. A cool one, with super hackers who read /. everyday, used vi/emacs on Linux, and just loved the command line. And they didn’t use version control(till a year later). Just goes to show, it’s not just boring old insurance companies that don’t follow the best practices. So at the time, I felt the need to backup my code. I hit the same problem I described above- code would work one day, and not the next. So I needed to be able to go back in time and look at old code.
I hit on the sexy and totally original idea of saving my code in folders. So at the end of the day, I would save that day’s code as “Code_folder <date>”. Hey, gimme a break. I was young and foolish, and ate a lot of wild mushrooms I found growing in the forest.
The approach, while inefficient, sort of worked. And then I read about SVN. I installed Torrtoise SVN, and discovered I could manage my code much easily with it. I created a repository on my hard drive(a bad idea, as if the disk failed, I’d lose everything; but still better than folders).
And that’s when I learned the fun of managing software. Even though Tortoise was quite mature at the time(this was around 2005), one day it crashed, and I lost all my data. I smacked my head and went back to using folders. It would be 2009-10 before Tortoise became stable. By that time, I was with a new company, and they installed SVN, making sure to use a stable version.
BTW, Tortoise is still an unstable piece of crap, as I will describe later.
What version control (VC) does for you
Version control is very useful. I discovered this the hard way, but VC allows you to do several useful things:
It allows you to go back to an old version of code, if you break the current code
The main purpose of VC
It allows you to see what other people in the team are doing.
Since every version control system forces you to enter comments, you can see what changes other people are making. Most VCs will allow you to setup emails, so you will get an email anyone checks in anything, if you are a control freak.
If the code breaks, you can look at the logs and figure out who last checked in the code (and then whip them, as is the tradition).
It allows you to create branches and releases
In the real world, you will often need to branch, or create a release. Branch is when you want to implement a minor feature, maybe for a client, and don’t want to interfere with the trunk (as you have existing users you’d rather not piss off). So you branch off, work on that branch, and merge back to trunk when you are done. Or, if you work in a messed up company, you keep the branch, and maintain hundreds of branches (see below).
You might also have releases: If you are selling installed software, and you release a version, you will want to create a special release branch for it. That way, you can fix bugs in that release only, without affecting the newer code.
Best Practices with version control
Try to keep branches to a minimum
Especially if you are working with centralised VCS, like SVN. And even more especially if you are working in the real world with real customers, and not on some hobbyist project.
The stuff of nightmares: You have ten different branches, and you keep seeing the same bug crop up again and again.
“But I just fixed that!”
“No, that was on the other branch.”
I mention real customers, as they will often come to you with weird requests (and also buckets of money; never forget that). You will have to create branches for them, if you don’t want to piss off your favourite customers. Branches can’t be avoided. What you should do is merge the branches back to trunk. That way, all bugs are fixed in one place, and one place only.
Check in every day, or at least every other day
This is easier with DVCS, but you can do it with SVN if you create a private branch. But with DVCS, it’s just so easy. Keep committing to your local branch, and push when the code works.
Automated / Overnight tests
You must have automated tests, that run each day. Overnight is a good system, as you can run multiple tests without worrying about slowing users. Seriously, it’s no good if you check everything in, but don’t test it two days before shipping (you do do that, don’t you? Admit it. I will not judge you).
Have I forgotten something? Please add in the comments below.
So which VC should you use? SVN or Git or Mercurial? Read on…