I have been writing on the topic of Version Control Systems. This is my second article in the Version Control Basics Series. If you want to know the basic definition, you can refer to my earlier article below.
I am assuming by now, you have a fair knowledge of what Version Control Systems are all about. Now, let’s dive a little deeper and learn what are the different types of VCSs the industry has witnessed so far.
Local Version Control Systems
These tools make use of local databases that maintain all the revisions to a file.
In the early days, a VCS tool called Revision Control System(RCS) was quite popular. It works by maintaining patch sets, on the disk in a special format. A patch is usually, the delta differences between the revisions. The tool was able to recreate what any file looked like, at any point in time, by adding up all the patches. But the downside to it was that it could operate only on single files. It cannot work with an entire project and hence does not support atomic commits affecting multiple files. So, only a single user could work on a file at a time.
Centralized Version Control Systems
Centralized Version Control Systems (CVCSs) maintain a single server that contains all the versioned files.
As it is a shared central repository, the best part is that multiple contributors can check out files and start working in parallel.
Of course, the downside is that the centralized server acts as a single point of failure. Examples include Subversion (SVN), Perforce, etc.
Distributed Version Control Systems
Distributed Version Control systems (DVCSs) fully mirror the central repository, including its whole commit history. Every clone is actually a full backup of all the data.
Now, if the central server dies, the local client repositories can be used to restore the data back to the central server. Examples include GIT, Mercurial, etc.
Thank you for reading. Hope to see you in my next article! Keep learning and growing. Cheers! :-)
