Version Control System is a necessary and an integrated part of any project development. There is a proverb suggesting “Necessity is the mother of invention” and the same applied to them. As and when required, new version control systems were invented and came into existence. In this article, we will go through evolution of version control system.
Increasing need to manage large projects easily and efficiently gave birth of different kinds of version control system. The basic purpose of VCS is to maintain and record the versions of a set of files or a file. It can also be used to keep track or version of software as well. In this article, we will take example of software source code having source files and how version control system can be used to track as well as keep versions of those source files. The files in the source code can be reinstated to previous versions before required code changes. In some cases, the whole project can be reinstated to previous version that was free of issues.
For example, a Java developer is working on a software project having some 100 files. He has used a version control system to keep track and versions of the source files. With every file he saves, the version control system is saving the state of the file as a new version. So by mistake, if he saves some erroneous file, he can reinstate that file to previous correct version with help of version control system.
Types of Version Control System
- Localized version control system
- Centralized version control system
- Distributed version control system
Localized Version Control System
As shown in the figure of localized version control system, a local version of the source files are maintained and tracked in a local computer by copy pasting the files. This kind of system is more error prone since the user may forget the path where files are stored. In some case the data may be lost due to hardware damage. This is also not very flexible since it becomes very difficult when large number of users have to work on different version of files at the same time.
Centralized Version Control System
As shown in figure, you can see there is a centralized server which has a centralized version control system like Tortoise CVS, Tortoise SVN, and Perforce etc. On these version control systems different versions of files are tracked and maintained. Here, multiple users can work on different versions of file at same time. The centralized version control system is able to handle such complexities. Different users can work on different versions of same file or different users can work on same version of a single file. In later scenario, where more than one user works on a same version of file, it creates complexities while committing or saving their changes. It is possible that the changes of one user can be overridden by changes of other user working on same file.
- Take an example of 2 Developers named “Dev1” and “Dev2” respectively working on a single file named “ABC.java”. Now both “Dev1” and “Dev2” has “X” version of file and they are working on it simultaneously.
- Now suppose “Dev1” has done some long and complex changes in file “ABC.java” and now when “Dev2“ tries to commit the same file he will get warning from version control system that there is a conflict between your local file and file present on the centralized version control system.
- Since changes were long and complex, “Dev2” did some mistakes and overridden code of “Dev1” and committed the changes. This results in creation of issues in feature developed by “Dev1”. This is the most common issue while working in a centralized version control system.
- One other famous issue in working with centralized version control system is that suppose “Dev1” is working on a feature and did like 20000 lines of coding. Now he has to take leave due to some emergency, so another user has to commit all that incomplete code in centralized version control system.
Centralized version control system does not have any intermediate or temporary space to save incomplete work of developer without committing it.
Distributed Version Control System
In Distributed version control system, each and every developer who checked out of codebase can make the local codebase act as a repository in which other developers can commit. Imagine a situation where 90-100 people are working in a global team. They can commit or rollback everything in each other’s codebase as well as in the central main repository. Let us see example using the above image.
- In above figure, “Feature 1” and “Feature 2” represents codebase in machine of developers “Developer 1” and “Developer 2”. These features were checked out or cloned from Central Server repository or main repository.
- Now “Developer 1” has 2 other developers working under him on “Feature 1” and “Developer 2” has 2 developers working under him on feature “Feature 2”.
- We confronted the issue of overriding code changes in a file when there is conflict between two or more developers working on same file in Cetralized VCS. Distributed version control system removes this issue and makes everything more easy and manageable.
- “Dev X” and “Dev Y” are working on “Feature 1” under “Developer 1”. “Dev W” and “Dev Z” are working on “Feature 2” under “Developer 2”. This statement means “Developer 1” and “Developer 2” has cloned or checked out codebase from central repository and named their local branch “Feature 1” and “Feature 2”.
- Since “Dev X” and “Dev Y” are working for “Developer 1” on “Feature 1” so they will take checkout of codebase from “Developer 1” machine instead of central repository or main repository. In distributed version control system, the local repository or codebase of a developer can also act a repository for other developers. And in same way “Dev W” and “Dev Z” will take codebase checkout from branch “Feature 2” of developer “Developer 2”.
- Scenario is “Dev X” and “Dev Y” are related with only feature branch “Feature 1”. If they commit or delete any file, it will affect the branch of feature “Feature 1” and not the central repository. Same goes for other two developers for feature branch “Feature 2”.
- Now say if developer “Dev X” and “Dev W” are working on same file and did lots of long and complex code changes than their commit will affect only their feature branch i.e. “Feature 1” and “Feature 2”. Thus the main repository or central repository remains unchanged or unaffected.
- After thorough testing if feature branches “Feature 1” and “Feature 2” are working fine than they are merged to main repository or central repository.
- Also if any emergency bug comes into production than say “Dev X” can make a new branch take update directly from main repository or central repository and start working on that branch. When that issue is resolved and code is committed to main repository or central repository, the developer again can switch to branch for working on feature “Feature 1”. This way a developer can work on main repository can also under feature branch of any other developer or lead.
The above thing just explained the benefits of distributed version control system in nutshell. There are several other benefits of it.
Hope you like the article and feedback is highly appreciated.