So, I’ve been working as a software developer for 2.5 years now. I’ve learnt quite a lot of things along the way, and I wanted to write about the single most important thing that every software engineer NEEDS to use throughout their careers – whether that’s a “professional in an office cubical, engineering software for commercial purposes” or “open source all the things” type (or anything in between).
Revision Control
To be fair this could be useful for almost any work that takes place using a computer.
We’ve all been there (and if you haven’t, then I’m sure that you will one day): you’ve just spent 7 hours writing some update to a piece of software – it’s a big update, fixing a lot of problems. You hit compile. You wait for the compilation process to finish. Then you hit debug and the compiled code runs.
Except that it falls over, massively. Errors everywhere; the screen goes blank; your computer reboots.
Damn.
Since you’ve had to save your code before building it, you’ve now lost the original (pre-changes) code.
Blast and damn.
Revision Control (or version control, or source control) is a type of application which keeps track of all the changes that are made to a given set of files – these can be code listings; documents; image files; anything really. Almost any type of file can be tracked by revision control.
To be honest, you can achieve version control manually by copying the files before you make any changes. The problem with this is that it’s manual, difficult and boring. For each backup you make, you have to come up with a new name for the backup (say a time stamp), and some description of the changes made to the code base that necessitated the backup – otherwise you have no idea why you backed up, or when you backed it up.
But, why not have a computer do that for you?
By having revision control software do that for you, all you need to do is come up with a list of changes that you’ve made and tell the revision control software to store those changes. You can even get the old versions of the files back.
I’m seriously surprised that most Universities that offer computer science related courses don’t teach revision control. Usually because it’s assumed that all students of CompSci know about them. I did, but MANY on the degree course I took didn’t.
But… There are lots of different ones. Which revision control system is the best?
That’s an impossible question to answer. I mean, they all do exactly the same thing, but in slightly different ways.
For instance, GitHub stores check-ins of code (the backups) on a web server. The code listing is publicly visible (unless you pay for private storage), which helps to foster open source development. GitHub actually runs Git (another revision control application, originally written by Linus Torvalds), and communicates with it to perform the check-ins of code.
Whereas, SVN (or Apache Subversion) has the same idea, but can be local or remote – the check-ins are either stored on the local machine (the one you’re using to write the software) or on a server (perhaps in some other country – this is called a Distributed Concurrent Version System or DCVS).
Almost all revision control software can be accessed via a GUI, the command line or through your IDE. Each system has it’s own set of commands, but the main commands will be variations on:
- Create a repository (where the code base for a single solution will be stored)
- Initialise a repository (create the folder structure, set a list of file types to be ignored, etc.)
- Perform a check-in (copy the changes to the repository)
- Perform a check-out (get the latest changes from the repository)
- Perform a branch (create a separate copy of the current version of the code base)
- Perform a merge (merge the differences between two branches of the same code base)
Learning how to do these things with code that already exists is a terribly important thing that all software engineers should do. You’ll have to learn to use them when you get into the industry anyway (even if you’re self employed or release everything as open source). And without them, your resume/C.V is going to look a little weak. After all, it’s one of the basics of software engineering; right up there with polymorphism, encapsulation, recursive programming and program flow control (if..then..else, for, while, etc.).
Here are some links to get your started on the road to revision control mastery:
- The Wikipedia entry for Revision Control can be found here: [LINK]
- OSS -Watch has a nice write up on revision control here: [LINK]
- Smashing Magazine weighs up the pros and cons of 7 of the big revision control programs here: [LINK]
- Git has a great explanation on revision control on it’s website, here: [LINK]
- There’s a great explanation from the SVN book here: [LINK]
Hopefully, this will help someone. Remember, check-in little and often and you’ll have no worries.
I can’t tell you how many times I’ve spent days writing some software, fixing some bug or other. Then when I’ve checked it in, the whole thing comes crashing down on account of some other part of the code base changing – colleagues kept making changes and now nothing works. Had I checked in sooner, it might have been avoided. However, the beauty of revision control is that you can get an extremely detailed view of what’s changed.
Until next time, stay frosty.
J
