Code The Game: Version Control for Dummies

This will be a three part series. Part 1 is aimed at the project leader. It explains why you need version control and how to set it up. Part 2 is aimed at the developer who will need to work with the version control, so covers how to use it. Part 3 is about conflicts and an other important topics.

The problem?
When you are writing programs on your own its quite easy to do, but what happens when there are two (or more) people working on the project together. What do you do?

Everyone hack the code & hope

Never going to work

Pass latest copies of the code about using email/thumb drives

Sort of workable, but its hard to know which bits have been updated
And you never know where the latest copy of the code is

Everyone writes their own code & gives it to one person who holds the master copy of the code

I've tried this, its a lot of work for the one person

Some kind of shared drive or drop box (http://www.dropbox.com/)

Getting there, but if you have to be careful, or you can overwrite each others code

A Version Control System

This is what I'm talking about

So what is it?
Think about a shared drive somewhere, which holds all your code.
It also holds all the backup copies of your code, so that every time you make a change, it makes a backup (just in case you mess it up).
It also keeps track of who have been changing what so it will stop you from accidentally overwriting someone else's code if you both have been making a change to the same file.

This is a version control system.

Different types of version control
There are quite a few different types of version control: CVS, SVN, Perforce, GIT, Mercurial, Visual Source Safe and many others. See http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
I'm currently using SVN, but they are all fairly similar.
(Note: those people who are familiar with distributed version control are entitled to scream at me for the previous statement. I don't use DVCS I know they perform a similar but in a totally different way)

A few terms
See: http://betterexplained.com/articles/a-visual-guide-to-version-control/ for a good summary.
I'm using the SVN terms as it will help later

Repository: The 'shared directory' where the code lives, usually on a hosted server somewhere
Import: take some brand new code & put it into the repository
Check out: Get a fresh set of the code (usually the latest version) from the repository onto your local machine
Update: Update the code on your local machine with the latest version in the repository
Commit: Copy the code from your local machine into the repository
Conflict: What happens when you try to commit some code and someone else has already made a modification to it

Getting started
You will need:

A repository

Since you want this to be accessible by your team all the time, its a bad idea to stick it on your machine (unless you have a spare server which you can use), so here are a few options. They all have free plans and many have paid plans too.

You only need one person to set up the repository, but you will need accounts for all your developers

A SVN client

I have used Tortoise http://tortoisesvn.net/ and Rapid SVN http://www.rapidsvn.org/
This series will look at Tortoise
Every developer will need one of these

Some code (duh!)

Setting up the Repository and performing the initial import
This is a little tedious, but only need to do once, so its a good idea to have your senior/experienced developer do this.

My example will be using https://riouxsvn.com/ and http://tortoisesvn.net/, but its roughly the same for all.

1. Go to your host and set up the repository

You will have to figure this one out for yourself. But it should be simple enough.

While you are doing this, look out for an option to create 'trunk' and all the other default directories.

(I usually do this, but I'm not 100% sure I really need to)

Once you are done, look out for the URL of your SVN repository, it looks like a normal URL. You will need this later.

2. Create an (almost) empty directory to put your code into

Advise: Never start by putting 300 files into your repository on the first attempt. KISS. If it doesn't work, its only one file.

As SVN cannot put empty directories into the repository, I always create a empty directory and put a readme.txt in there, then import this.

Note: I like to add the entire directory into source control. This gives me the option to put multiple project into one repository if I want. I'm not sure if its a best practice, but it seems logical.

Right click on the new DIRECTORY (not the file), and import it.

When the dialog appears you will need to enter the URL of the repository which should be of the form:

https://whatever_the_SVN_repository_was/trunk/project_name

(Most will be https, though it might be http)

You need to get this first bit right, or you will hit all sorts of problems. I always have project_name as the same as the directory, mainly for convenience. I never have spaces or strange characters in it. And remember to choose a suitable name too. (I have an SVN project called 'labtask', oops!)

It might ask you for your username & password, but you should soon see a result like this: