Version control (also known as Revision control or Source control) is the management of different versions of files. I don’t know how large development teams could survive without it! Typically they all have one thing in common they help multiple developers contribute to a single project using an central server.

But how can it help? Have you ever worked on a project with someone else and had your files overwrite your files? Or constantly had pop your head over the fence to say “I’m going to work on file abc.xyz, okay?“. Preventing this is the selling point for me!

Version control systems can achieve this in either of the following ways:

• Locking - The simplest style is locking a file so only one person can modify it at a time. A file is checked out by one person then later checked back in.
• Merging - The more productive method merges multiple versions together. This way two people can work on the one file at the same time merging their changes when finished.

I’m going to concentrate on merging although locking is not without it’s benefits. Regardless of your system you should be familiar with some techniques used. This includes the conventional directory structure:

/branches/
/tags/
/trunk/

Or if you choose to have multiple projects in the one version control project:

/project-1/branches/
/project-1/tags/
/project-1/trunk/
/project-2/branches/
/project-2/tags/
/project-2/trunk/

Each of these top level directories has a specific purpose:

• Trunk - Where you’ll find the main line of development. Which is basically the primary repository for your code!
• Branches - Can contain multiple branches, each once a copy of the trunk that has branched off into a separate line of development.
• Tags - Contains tagged (as in with a friendly name) copies of the trunk from a specific point in time. Primarily used for taking snap shots of your released versions.

Branches can be used in two ways in my opinion:

• a unique development line never intended to be merged with the trunk - an example being one client has unique needs not beneficial to others.
• a development line which is intended to be merged with the trunk, but requires significant work which might have caused disruptions to progress on the trunk.

Where and how you work depends on your project, development team and what you’re working on!! A branch could be used for each developer working on a separate component not yet ready to be placed in the trunk. Alternatively smaller teams maybe comfortable all working in the trunk directly.

The sequence diagram below shows how a user might create a branch of the trunk and continue to work on it until merging it back in to the trunk.

A good practice shown above, is to merge the trunk into the branch periodically. This makes the process of finally merging the branch into the trunk more manageable! Additionally you should do this again immediately before merging your branch into the main line of development once it’s complete…

There are a number of different systems, my preferred is Subversion (SVN) , another common one is Concurrent Versions System (CVS)… Here are some websites that helped me get my head around this:

• The Top Ten Subversion Tips for CVS Users
• Version Control with Subversion - Branching and Merging
• Revision control - Wikipedia

I’m reasonably new to this so… Please let me know if you’re aware of any corrections required to the above!