How many types of Version Control Systems are there?

 Hello everyone. Welcome back to this session. So today in this session, we’re going to discuss the types of version control systems which exist in the industry right now.

Alright, so typically there are two types of version control systems, which are central version control systems and distributed version control systems. Now exactly what is central and what is a distributed version control system? Let’s discuss that.

Types of Version Control Systems

Centralized Version Control System

Alright, let’s discuss the types of version control systems! so in the centralized version control system, you have one server to which all the developers connect, right? This is the first point that you should notice. So centralized version control system has one single copy of code in the central server.

So like I said, there is one server where everything is stored and the developers directly connect to the server for getting the copy of code that they require. OK, if the developers have to save their code on the server, they’ll have to directly do that.

And if they have to download it, they’ll have to directly do that. Alright, so developers will have to commit their changes to the code to the central server. And committing just means saving your files on the server. In git terms, you would say pushing your files on the central server.

Distributed Version Control System

Alright, moving forward now let’s see what distributed version control system is. So in a distributed version control system, what happens is of course you have a central server where all your files are stored, but at the same time you have a local repository as well.

Now what is the local repository? Whatever repository is there on the remote server or the remote repo is also copied and saved on the local repository.

OK, so in distributed, VCs 1 does not necessarily rely on a central server. That means I do not have to be connected to the remote repository once I download the repository on my local system.

OK, if I compare it with my central VCs. The problem was that only the file that I wanted would be downloaded to my system, not the whole repository, right?

For example, if in my code base, I have done around six months of work there will be a lot of version history in that repository, right? However, when I am working with a centralized version control system, I do not get the version history downloaded on my system.

Alright, if I want to go to a particular version, I can only download that particular version, and that too once I connect to the central server.

But in a distributed version control system what happens is you have to just connect to the remote repository once you download the repository on your system and then you can commit your files to the local repository itself and there is no Internet connection required to connect or to save your files on the repository.

Once you save the file on your local repository and you want to put any field you know everything is done. Everything seems fine. Only then you would need the Internet connection to push these changes, the changes that you made to the local repository to the remote repository.

But if I want to go to a previous version and if I say I want to revert to a previous version, all of that can be done on the local repository itself.

So in in short, if I were to say the version history is downloaded also in the distributed version control system, but it is not the case in the central version control system. OK, so every developer clones a copy of the main repository on the local system as we just discussed.

This also copies all the past versions of the code on the local system. So you also download the version history alright. Therefore the developer need not be connected to the Internet to work on the code.

So if you want to go to a previous version, if you want to revert to a previous commit, you do not need the Internet connection.

But if you were working on a central version control system, you needed to have that Internet connection for any kind of operation if you wanted to do it on your central version control system, OK, now I will tell you some differences.

The difference between a Distributed Version Control System (DVCS) and a Centralized Version Control System (CVCS)

Now let’s see some more differences between both types of version control systems. The centralized version control system and the distributed version control system. So these would just summarize what we discussed so far.

 OK, so distributed VCs, everything except pushing and pulling. That is pushing your changes to the remote repository or pulling the new changes from the remote repository. Only for that, you would need an Internet connection.

Except that everything like if you want to revert something, if you want to go back to a previous commit, if you want to save your file. All of that can be done on your local repository as well. For that, you do not have to rely on an Internet connection.

OK, if you compare it with centralized VCs, you need a dedicated Internet connection for every operation you want to do on it.

OK, the second thing is every developer has a full version history and over here you do not get the version history. That is also a good point.

The third thing is committing and retrieving action is faster. The reason is that you’re doing it on your local repository, right? So if you have to save files to your local repository, it is faster.

But in the case of central VCs, even if you have to save a file on the repository so that it gets versioned, you need an Internet connection. It will not get versioned if you’re not connected to the central server.

In this case, in the case of distributed, it will be versioned the moment you save it on the local repository as well. OK, so the actions that you do on distributed VCs are faster than on the central VCs because there’s no need for a network connection in the case of distributed VCs.

OK, so distributed VCs on the other hand are not good for storing large binary files, because this would increase the size of the repository for any person who wants to download the repository.

For example, you’re storing large video files on your git repository, right? In that case, what would happen is any developer who now wants to look at the code and has not downloaded the repository yet, has to 1st download the repository and you know he’ll have to download the video files as well which come with the repository.

And because video files are large files, they could go in GBS. It takes a lot of time to download. Now another important thing over here is because you’re dealing with binary files, git is not able to recognize the changes that you do to binary files.

For example, you had a video file first, then you made some changes to it and now it becomes say it’s a video file version 2. Now when you again upload it on git, it will not save just the changes or the video file.

It will keep that video file as a separate file, although it will mark it as version 2, but it’ll be uploaded as a new file. Now imagine because version history is downloaded in distributed VCs.

Now imagine if you have six or seven versions of a 1GB file on your git repository. Then any developer who will be downloading this repository will be getting 7 GB of files on a system when he’s pulling the repository on his system.

Now that’s a huge number and that’s why if you’re working with binary files, distributed VCs are not recommended for you. OK,

On the other hand, because centralized in centralized VCs, you do not have to download the version history while you’re working with files.

It becomes a boon when you’re trying to deal with binary files. So if you have a project where you have to deal with binary files, there are large files that have to be stored.

You can store it on centralized VCs because it becomes easier to work on it right? At the same time, versions are also being maintained. That is a different story in that it is being maintained on the central server.

So if you want a previous version file, all you have to do is download the previous version file from the central server. That’s all you have to do, right? But because the version history is not downloaded, so you’ll always always get only the latest version of the file.

So for example, if the new file is here on one point 2GB, right? So now when you download the file, you’ll only get 1.2 GB, you’ll not get the previous versions on your system.

So hence it is more helpful when you’re storing binary files when you’re dealing with centralized VCs. OK, so these are the differences between distributed VCs and centralized VCs.

So now you know when to use what. So if you’re dealing with binary files, in that case, I think the better way to go would be centralized VCs. If you’re not dealing with binary files, the better way to go is with distributed VCs. Okay going forward.

What Sub-Version and SVN are?

Now let’s look at some examples of centralized version control systems. So you have Subversion and then you have Helix code. OK, so the sub-version is Apache software that was developed in 2000, right? So let us look at what sub-version and SVN are.

Subversion

So subversion is a software versioning and vision control system and it is distributed as an open source software. Since it’s open source, a lot of developers, not a lot of developers as Git or any other open source software.

It’s a very small community, but still it’s very active. They are actively working on adding new features to SVN, right? And it is still open as an open-source project. So if you want to use Apache, it’s free of cost, you can download it and you can be a part of the open-source community as well If you want to add any features to this particular software.

Disadvantages of SVN?

OK, now because SVN is not so popular with software companies. The reason is, that software companies do not deal with binary files, right? They deal with software, they deal with text files more than binary files.

Hence SVN is not particularly used in software companies as much as we use Git, right? But I’d say that we do not use a centralized version control system much in companies than a distributed version control system.

Some companies are still working on a centralized version control system, the reason being that probably they’re working, they’re still working on their legacy software, right?

So if they move to a newer version of the version control system, it will probably cost a lot to them because the code base exists on SVN right? For those reasons, some companies might be following this rule of working on the centralized version control system.

However, most of the companies that deal in software are working on distributed version control systems. The reason is that if you talk about SVN, it constantly needs an Internet connection because this is a software of centralized version control architecture.

The version history is not downloaded. So you cannot work on the local system completely. You have to be connected to the Internet to download a previous version’s file, right?

It is slower than a distributive version control system because of course there’s a network connectivity required and if there are any conflicts in the file they have to be resolved manually.

In the case of git, they can be done automatically as you will see as you progress along in this module. But in the case of SVN, they have to be done manually.

And that is the reason this SVN is not that much preferred when you talk about companies who are dealing with software. Now let’s talk about the examples of distributed version control systems.

Examples of Distributed Version Control Systems

So you have software like Perforce, you have Git, you have Mercurial. And out of all of these, the most famous one is Git. OK, so I’m going to show you guys some graphs in the next articles related to Git.

We’re going to show you some market research to prove whether Git is the most popular tool or not. And that is the sole reason you’ve also picked up Git for this particular course, because we want you to learn the technology that is most relevant for you in the industry, right?

The Bottom Line

In conclusion, understanding the diverse landscape of version control systems is pivotal for effective software development. The exploration of various types of version control systems, including centralized and distributed models, highlights the significance of choosing the right approach for collaborative coding endeavors.

As developers navigate the dynamic realm of software evolution, implementing a robust version control system becomes indispensable. The careful selection and adept utilization of version control tools not only enhance team productivity but also contribute to the overall success of a project.

Embracing the versatility of version control empowers teams to seamlessly manage code changes, track revisions, and collaborate efficiently. In summary, the exploration of different types of version control systems underscores their role as foundational pillars in the realm of modern software development.