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.
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)