What is a Version Control System?

Managing your Development

What is a Version Control System? Once you have been developing on your own for a while without using a VCS, you'll realize that

• It's easy to delete parts of your code that you need.
• Even if you are diligent about keeping past versions, it's easy to get mixed up.
• Managing different versions and working out what's different can be tricky. lli]Backing up your work automatically.

That's just when it's you. Now try working in a team. Even with just two of you, that's two sets of files that need to be kept in synch. As the team size grows. it will become a bigger problem and you'll waste more and more time trying to keep on top. There's nothing worse than having two people working on the same file and have one overwrite the other's changes. A VCS will eliminate most of this wasted time. Computers can crash but if you have the VCS repository automatically backed up each night then you get all the checked in code saved.

A VCS is a software repository, which is just a fancy name for a database that manages all your files and provides access to them through a web interface or sometimes a GUI or command line interface. A VCS will let you keep past versions of files and let you compare any two versions so you can see what has changed.

Server or Distributed

Originally VCS systems, such as PVCS from the mid 90s, were file based on a network but with the increased take up of the web client-server systems became popular such as CVS or Subversion and in the last few years distributed VCS have appeared. WIkipedia currently lists 11 distributed VCS including one (Git) written by Linus Torvalds of Linux fame.

Web-server based systems such as Subversion are useful in distributed teams as they work across the Internet. Clients have been written like Tortoise (for Subversion) that integrate with Windows explorer and provide a very convenient way of checking in files. I've listed three web based services at the end of this article.

A Glossary of VCS Terms

VCS have their own terminology so here's a quick guide to the most popular words and phrases. These tend to be common across most VCS systems,

• Build. Build Systems generally work on files that are checked in. To do a build the first step is fetch all checked in

• Branch. VCS are generally used in conjunction with build systems. As a project is developed, there will be alpha, beta, and full releases etc. Then bug fix releases etc or perhaps even a separate version of the project for new hardware, or a special customer etc. A copy is made of the project and this creates a new branch. The main branch is usually called head and this is where most development takes place unless it is required in a branch say to fix a bug particular to that branch.

• Checking In. The process of returning checked out files into the repository. Some VCS lock a file once checked out so only the developer who checked it out can work on it. Others e.g. Subversion let anyone work on a file but warn you when you check it in so that you can merge your version with other changes in the same file instead of over writing it.

• Checking Out. This tells the repository that you are working on one or more files. Other VCS users can see who has a file checked out. Once you are finished working on the file, you check it back in. This creates a new revision of the repository. You can check out any version of a file from any branch, but unless you are doing a fix in a particular branch, you'll usually only check out from the head.

• Diff A utility that lets you view differences between two versions of a file and highlights the differences. Some diff utilities also let you merge.

• Fetch The act of extracting all files for a build. Fetch doesn't check the files out, just makes a copy.

• Head. The main development branch. Think of development as tree growing upwards. Branches emerge but the head (ie the top of the tree keeps growing).

• Label. A way of referring to a file or set of files. In some systems e.g. Subversion, labels and branches are the same.

• Merge. This is what you need to do if both you and another developer have made changes to the same file at the same time. When you try to check the file in, you get a warning and some VCS Diff utilities will let you copy lines between the two files so you can resolve the conflict and end up with a merged file.

• Release. Its quite usual to organize the structure of the repository with a branch for each release of the software. You'll develop the software and test until you are happy with the quality of your code. You then create a new branch for that release which is a copy of the head branch.

• Revert. Cancel a check out on a file you have checked out. It reverts to its state before you checked it out.

• Repository The name for the database that holds all the files. Some VCS can hold binaries as well as source code in their repository.

• Revision. Every change to a repository, though adding new files, checking files in, renaming or even deleting files in the repository, creating branches etc creates a new revision. In subversion, a revision is just a number that gets incremented with every change.

• Tree. The overall structure of files in the repository.

If you are a single developer working alone, I'd still recommend that you get up to speed with a VCS. If you ever intend to work in a team, the experience will be beneficial.

You can try these web based Subversion hosting websites for free.

• Opensvn.csie.org (Taiwan- Republic of China- run by enthusiastic students). This can be a little slow but there are no limits to project size. However it's possibly a little unreliable as they lose backups!
• assembla.com - Includes trac and Wiki and other tools. Free up to 200 Mb but then paid after that.
• devjavu.com (Not to be confused with the adult site dejavu.com) - Free by invite or commercial.