Comparison Between Centralized and Distributed Version Control Systems

Version Control Systems were introduces in development works long back and we are using it for a while now. Like all other development aspects we have come across many feature upgrades and modifications for Version Control Systems as well. So far there are two types of Version Control Systems we know about: Centralized Version Control System (CVCS) and Distributed Version Control System (DVCS).

If you want to get a basic idea of what a Version Control System is, you may read my other article What is Version Control System (VCS) – General Idea.

First let me tell you the major differences between the approaches of keeping revision histories by a Centralized and a Distributed Version Control System.

Repository: In Centralized Version Controls systems the entire codebase is located in a central server. Developers check-in and out files they work with and the updated file goes back to the same repository. With every revisions, Centralized Version Control system creates a new file and keeps a historical database or log of the same. On the other hand, A Distributed Version Control system uses a peer-to-peer approach. In this approach there is no cetralized location used to store the codebase, rather each peer has its own at their local development environment. This gives Distributed Version Control systems the great power to maintain backups in different locations. Unlike Cetralized Version Control systems, Distributed Version Control systems does not have the fear of central repository to get crashed and all hard works are destroyed!

Working Copy: Unlike Centralized Version Control System, every single developer working in a project which is managed with a Distributed Version Control system, will have their own code base at their local. In a Centralized Version Control system, even there are multiple developers working in a project nobody has a true clone of the the code. It is only available in the central repository, i.e. in the server. So with DVCS, every developer has his own “working copy” in place which they can keep working with even without fetching anything else from there central repository. This is however, not the way of using DVCS or this is not something DVCS is out there for you , but the possibility is always there.

Workflow Diagrams: The following diagrams shows how Centralized and Distributed Version Control systems work. As you can see, in Centralized systems, you always have to reply upon the online repository in order to keep your work history going. On the other hand you can keep your work history completely private from the world as long as you want by using your own local repository which is residing on your own system itself.

Centralized Version Control System workflow diagram
Fig. 1: Centralized Version Control System workflow diagram


Distributed Version Control System workflow diagram
Fig. 2: Distributed Version Control System workflow diagram

Keeping Work History: This is probably one of the major and most important breaking changes Distributed Version Control Systems have come up with compared to that of Centralized Systems. What is this actually? How does this help a developer? When we talk about Version Control systems, it is obvious that we have the ability to keep a log of all our works we have done and can review them by jumping into that version at any point of time. However, the major difference between two types of control systems is Centralized systems keep this on the remote server whereas Distributed systems first keep a copy of this log on your system (when you Commit locally), and then when you Push it to the central code repository, it gets added there.

One more magical advantage that Distributed systems provide is that you can commit your works locally and it will keep a log for you. For example, you are working on a module where you have done a bit of work already. At this stage rather than leaving the code like this, you would definitely want to keep a backup somewhere because your work is not completed so you cannot push it to the central repository yet. How will you make sure that your work history is maintained. Well, Distributed Version Control systems give you the flexibility of Committing your work locally. In Centralized systems, if you want to do this you have to Check-out to the central repository directly and if your code has errors, everybody will suffer from this.

So, Distributed systems give you the power to keep your work logged locally as well as to decide when to push your code to the central repository.

Freedom to Work Locally: While working under a Centralized Version Control System, as mentioned above, you cannot push it back to the remote repository unless your work is done and error free. If you do so other collaborators, when pull latest changes, will encounter the errors. On the other hand, Distributed systems let you save your partial works by means of committing them locally. By doing this, you make sure that your work is now recorded into your local repository but it will not harm anybody else in your team. Once your work is complete and you are ready just push it to remote repository.

Popular Centralized and Distributed Systems: Although a Distributed Version Control system is proved to be more powerful, Centralized Version Controlling Systems are still out there and making its way. Most commonly used CVCS are CVS, SVN and Perforce while Git, Mercural and Bazaar are among the most popular DVCS till date.

Popularity Comparison: Since 2004, it has been observed that Distributed Version Control systems (Git) is taking over Centralized Version Control systems (SVN). However, there are still a few countries like Morocco, Tunisia and China where CVCS are still maintaining its popularity over DVCS. You can visit Google Trends to see how these two version control systems are performing across the world since 2004.

Further Reading: What is Version Control System (VCS)

What is Version Control System (VCS) – General Idea

What is Version Control System?

Version Control Systems are meant for tracking and keeping a history of changes you are making in your project files over time. It ensures that all changes are being saved in a location but each such change is tied up with some sort of versioning. The magic of versioning is that you can easily recall a specific version at any point of time without affecting any other changes that are saved in other versions. The concept of versioning is not only limited to development, but you can use it for other purposes as well. For example, you are writing a long and critical research report which can take long time to finish. If you save your everyday’s work with a specific version or under some system which creates versions for you, it would be very helpful for you to refer or even switch back to a particular version number easily whenever you want.

How Version Control systems makes developers’ lives easier

Not all the time you are working on something or in a project where you are the only one dealing with it. Rather when you are a developer in a development team, you may be accessing some parts of the code in a project which other developers in your team too can access. Thus changes made in one part of the source by one developer can be incompatible with those made by another developer working at the same time. Situation like this can easily be solved by implementing a Version Control system, bring the project and all developers working in that project under it all changes and activities can be tracked and logged in such a way that a developer can have the ability to go back forth between versions during development process. How?

  • A complete history of every file, which enables you to go back to previous versions.
  • The ability to work on independent streams of changes, which allows you to merge that work back together.
  • The ability to trace each change with a message describing the purpose and intent of the change.

Centralized Version Control System (CVCS)

In Centralized Version Control Systems, you have a single “central” copy of your project located on a server remotely and commit your changes to this central copy. You pull the files that you need from the server, but you don’t have a latest complete copy of the project at your local development environment. Some of the most common version control systems are centralized, including Subversion (SVN) and Perforce. A popular SVN is Tortoise SVN.

Distributed Version Control System (DVCS)

With distributed version control systems (DVCS), you don’t rely on a central server to store all the versions of a project’s files. Instead, you clone a copy of a repository locally so that you have the full history of the project. Two common distributed version control systems are Git and Mercurial.

Know more about CVCS and VDCS: Comparison Between Centralized and Distributed Version Control Systems