Revision control is a little like insurance. You never see the value of it until you actually need it. Some programmers never touch it, while others swear by it. Revision control does contribute huge benefits while also introducing a small overhead on project management. I personally feel every project ever developed should always be placed under such a management system and here’s why.
First of all, what is revision control?
Any revision control system is basically an enhanced database (called a repository) of a particular project’s source code, which allows you to track authors, files and more importantly, changes. It allows an individual or a team to contribute to a project while giving the opportunity to review all changes against old versions and if necessary roll back a particular change.
This also enables the project to be easily ‘branched’ in order to provide a duplicate project that can be independently worked on (maybe to add an experimental feature) then later merged back into the main ‘trunk’ of the original project.
Client/Server based revision control
One type of revision control is server based where you have a central repository hosted on a local server or maybe located on the internet. This server houses all of the source code and developers ‘check out’ a file, change it and then commit the changes back to the repository, ensuring other developers can see and access the changes made.
Examples of such systems are:
Distributed revision control
Revision control systems that have become popular recently are the ones which allow the repository to be decentralised, to allow all developers to have a local repository, to commit changes to and to keep updated. When this local repository has been updated with their changes, a change set can be forwarded to other people who have the same repository (or even a central server based repository) to update theirs to the new changes. This is called a distributed revision control system because it doesn’t need to be hosted on a central server and is very much ‘peer to peer’.
Examples of such systems are:
So why use a revision control system?
In my opinion, revision control is essential for doing anything even remotely professional either singularly or in a team. I don’t mean using it will make your code any better but only that you will have full control over every aspect of every edit you make to your code base.
For example, what if you spent a few hours adding a new feature to a project, changing multiple files, only to discover that it didn’t really work out and you want to roll back to an earlier state? Or maybe you notice a small bug that crept into a reliable module and wanted to check want changes were made in the last month? Even get a nice diff to show the changes? Maybe you like to ship what you have now as version 1.0 and branch the project off to become version 2.0 adding more features, while still maintaining bug fixes for the previous unchanged version? The advantages are endless.
There really is no case for not using a revision control system. Using one, all edits are recorded and every change can be viewed or rolled back to a previous state. It’s a god-like undo button that records the life and previous history of any file put under its control.
Download one now from the above lists and give it a try.