All Version Control Systems are divided into two types.
Centralized Version Control System
Decentralized / Distributed Version Control System
Centralized Version Control System
This type of Version Control System contains only one repository. Working directories may have multiple files, but there will be only one central repository and every developer is required to connect with that to continue his / her work.
Let's assume we have a central repository server.
In the Central Repository, the data will be stored in the form of versions. So, assume multiple versions are there in the central repository.
Now, assume that there are multiple developers. And every developer is required to connect with the Central Repository to continue the work.
Now, in the Developer’s workspace whatever files the developer requires, he’ll get that version from the central repository and then he will work on the project.
Assume that there are several files available in the Developer’s workspace. That is whatever he /she is going to provide to the central repository or whatever he /she is going to get from the central repository.
If a developer is required to work, he’ll connect to the central repository and will get the required files and then he’ll start working on those files.
The developer will get the files in two ways:
He may create new files/files.
He’ll get / checkout from the repository.
After completing the total work i.e changes in the code, he/she has to commit that work to the central repository.
Developers submit / checkout those files only in which he/she is making changes. But all the files will be present in the central repository.
The same goes for multiple developers working on the same project, so every time they are required to communicate with the central repository, then they will get / checkout some files and after completing the work they’ll commit the changes to the central repository. As version control is happening in only one place that’s why this model is considered the Centralized Version System.
The total project code will be stored in the central repository.
All operations will be performed on the central repository but not in the developer’s workspace (It contains only dummy working files).
It is very easy to set up and easy to use.
Centralized version control system tools:
CVS
SVN
Perforce
ClearCase
TFS etc.
Limitations Of The Centralized Version Control System
The total code/files are stored at a single place (Central Repository), So if something happens to the Central repository server, then the recovery is very difficult which causes a Single Point Of Failure.
If developer “A” wants to perform the checkout operation, then he/she has to connect with the Central Repository Server (Remote Repository Server) and then get the files.
So, the checkout operation happens over the network by connecting with the remote server, and then he wants to commit the changes. So, the commit operation will be performed on Central Repository Server. So, all the developers should be always connected to the central repository. So, if the network outage (Cutdown) will happen then the Version Control won’t be available for the developers as they’ll not be able to communicate with the Central Repository until the network availability.
As for every operation we have to connect to the remote Central repository. It’s not a local operation, so it’s going to take time, which will affect the performance (It’ll be low).
If the number of developers increases or the number of files increases for Version Control, then the organization of the central repository is a bit difficult.
Distributed Version Control System
In this type of Version Control System, the repository is distributed. If four developers are there then 4 repositories will be there.
Distributed Version Control System Model
Assume that there is a developer’s working directory/workspace.
In the previous model, the working directory/workspace contains only files, not versions. But in the Distributed Version Control System, every workspace has a local repository.
So, if 10 developers are there then every developer will have their own local repository, and then there is no question of the centralized repository.
All the versions will be maintained in the local repository.
In the working directory, he /she (the developer) is going to work with files.
Now the developer wants to perform the checkout operation. So, the checkout operation will be performed from the local repository. He /she is not required to connect with any remote central repository.
Now, he works on some files and wants to perform the Checkout operation. So, the commit operation will be performed from the local repository. He /she is not required to connect with any remote central repository.
Advantages Of Distributed Version Control System
So, the biggest advantage is all the commits and the checkout operations will be performed locally and hence the performance will be more.
Even with a network outage, the version control will be available, so the client machine/developer’s machine need not be connected always.
Suppose if the remote repository is there, just for the sake of sharing, network issues must not be there.
Every developer has his / her own local repository (in the developer's machine), that’s why there will be no Single Point Of Failure.
Q. All the operations (Commit & Checkout) are happening within the same system only, so how do the developers work in a collaborative way means how will the developers share their work with the other developers?
Ans: So, here also all the developers can work collaboratively.
How is that gonna happen?
Let’s consider four developers working on the same project.
Every developer has their own local copy of the files (project).
Now, if developer A wants to share his / her files with developer B. So, now he/she will push his / her repository to another developer’s (Developer B) repository.
This operation is considered the Push operation.
Push: The process of sending files from one repository to another repository is considered the Push operation.
So, if we want to send the changes of our repository to the other developer’s repository then we have to perform the push operation.
So, whatever changes we’ll do in our repository will be Merged into the other developer’s repository.
And now, if Developer “D” wants the changes of developer “C”, so he/she now he’ll get them from developer C’s repository.
This operation is considered a Pull operation.
Pull: The process of getting files from another's repository to our repository is considered the Pull operation.
Decentralized version control system tools:
Git
Mercurial
Fossil
Distributed Version Control System With Remote Repository
It’s not the mixed approach of the Centralized Version Control System and the Distributed Version Control System, It’s Distributed only.
Let’s assume there is a working space for Developer A. It’s having Working Files, Versions under the Local repository.
Let’s assume multiple (four) developers are there.
Now, here we’ll maintain one remote repository server.
And in the Remote repository, we’ll have multiple versions.
Now, suppose there is a new Developer i.e Developer A got assigned to work on the project. He does not have anything in his local machine.
So, he’ll perform the Pull operation in order to bring the files from the remote repository to his workspace. We can use the word Clone if we are pulling the files from the remote repository for the first time.
Now, the total repository will get to developer A’s workspace.
Now, he can perform all the operations on his local machine (Commit & Checkout), and after performing all the changes in the files/codes he will perform a Push operation in order to share his code/changes with the other developers.
The same goes for other developers as well. If they want to get the latest version of the files/codes, then they will Pull the code from the remote repository and after performing all the changes in the files/codes they will perform a Push operation in order to share their code/changes with the other developers.
Instead, there is a remote repository, then also we can’t use the word centralized version control system.
Remote Repository Vs Centralized Repository
In the centralized repository, we are performing the Commit & Checkout operation on the centralized repository. But in the case of a remote repository in the Distributed Version Control system, we are performing the Commit & Checkout operation locally.
In the Centralized Version Control System, there is only one repository. But in the Distributed Version Control System, every developer has their own local repository.
- That’s why even adding the remote repository server it’s not the combination of a Centralized Version Control System & Distributed Version Control System.
Q. Now, if we are not performing any Commit & Checkout operation in the remote repository then what is the use of it?
Ans: The main use of the remote repository is just to share the changes with the other peer developers.
Q. From where the final project is going to be delivered?
Ans: The final delivery of the project is going to be delivered from the remote repository. But we are never going to develop any code in the remote repository. All the code development and then Commit & Checkout operations are performed locally on the developer’s machine.
Just to merge (Get & Share the code/files) the local repository with the remote repository we are gonna use Pull & Push operations.
Remote Repository Server tools:
Github
Gitlab
Bitbucket
Cloud Platforms