What is Version-control?
Software Developers all around the world write large pieces of code that are aimed at doing complicated things. These lines of code can range into thousands. Just to give you an idea, the source code of the Linux kernel is about 15 million ! Obviously, such large pieces of code must not have been written in a single day. Also, as the code was written, numerous edits must have taken place, in order to remove bugs or to add new features. Now, imagine that while finding a bug in our code, we accidentally screw up badly, how do I get back to my previous code? That is where Version-control comes in.
Version-control basically means a mechanism that saves all version of your code and keeps it safe, so that if at any point you want to go back to a previous version of the code that you had written, you can easily checkout that version of your code.
If you are designer or developer, VCS or Version Controlling Software are very useful tools to use, as it allows you to immediately to go back to a previous version of your project and even compare changes between two different versions and track changes that you have made to your project.
There are mainly three different mechanisms by which this is done:
1. Local version control systems
Many developers like to store different versions of their code in a directory, maybe with a timestamp. However, this method is prone to errors as one might easily copy a the new version into the wrong file or overwrite a previous version.
A better method would be to maintain a database that keeps track of all the changes that have been made to a file, preferably storing different patches of the code that have undergone changes. This way whenever we ask the VCS for a previous version of the code, it can sew up all the patches together and present us with the required version of the code.
This is what the Local version control system does. An example of a local version control system is RCS. Even popular OS-es such as MacOSx offer “rcs” command to keep track of the changes made to a piece of code. However, a con of this kind of system is that all the data is stored in one place and hence, if the source system goes down, then all the data is lost.
2. Centralized version control systems
Collaboration is difficult in Local VCS’s. This can be worked around by storing all the changes made to a project on a centralized server. This way everyone knows where everyone is with the progress they have made with the project. A single server machine has all the versions of the code, and various clients can request various versions from this system. However, here again, we have the same con as with Local version control systems. As all the data is stored in a single place, if proper backup is not maintained, corruption of the system can lead to permanent loss of data and progress.
Examples of this kind of system are : CVS, Subversion, Perforce
3. Distributed version control system
To overcome the cons of the above-mentioned systems, we have Distributed VCS. In this system, each user makes their own personal copy or “clone” of the original copy of the code. This way collaboration also becomes easier and at the same time, in case the original file is lost, it can easily be recreated from the copies maintained with all the people who have cloned the repository.
Examples are: Git, Bazaar, etc.
- Progit by Scott Chalcon and Ben Straub