Why use a version control system

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…

2 thoughts on “Why use a version control system”

  1. Small software house. 6 developers.It took me 2 years to drag the team into version control and I still get told it’s rubbish when they use it incorrectly.

    If you are not using what I now call “collaboration control”, you are digging trenches with a spoon, and good luck but I’m out of here,

    Why version control?
    which folder has the most recent code for that client ?
    what broke the latest version I built ?
    what changes have been made to the clients latest live release so I can work out what might have broken it at 2:00am
    my disk got wiped, I’ve lost the last weeks work!
    have I got the changes that developer’s x,y,z made last week ?
    take your pick.

    Which VCS.
    I played with SVN, nope. Mercurial, better but DVCS meant that everyone commited locally and we ended up with unmergable code, nope. Discovered fossil.

    Why fossil?
    1. Checkin comments can be altered and clarified when you see them in a month’s time and wonder WTF that description means.
    2 Single exe. No install.
    3. We copied the Apple OSx version to the Mac Mini server with the repositories on, to serve the Web front end. Windows exe on the Win7 dev machines.
    4. scriptable.
    5. relocate repositories with a simple copy.

    I did end up writing a right click context menu front end so I could enforce some rules regarding repository locations, adapt to Windows where file names are not case sensitive, etc. and nobody had to remember any commands.( 2,500 line batch script fine )

Leave a Reply