Version control systems (VCS) are tools used to keep track of changes to source code or other collection of files and folders. Version Control system tracks the history of change to some set of document. It facilitates collaboration. Version Control System track changes to folder and its contents in a series of snapshots. So, we capture a state of the folder. Each snapshot encapsulates the entire state of file/ folders within a top level directory. Version Control Systems also maintains metadata like who created each snapshot, messages associated with each snapshot.
There have been many strategies to implement version control in a system. Let us dive into some of the types which got implemented over the years.
Local Version Control System
As the name suggests local Version Control System was developed to track changes of files and folders within the local computer of the user. The local VCS was developed as a simple database that kept all the changes to files under revision control.
Revision control system (RCS) is an early developed VCS primarily to perform this task of localized version control. It works by keeping patch sets (i.e. the difference between files) in a special format in disk. It can then recreate what any file looked like at any point of time by adding up all the patches. Popular operating system like popular Mac OS X includes the rcs command with their Developer Tools.
Centralized Version Control System
The Centralized Version Control System was developed for promoting collaboration with developers across systems. The systems like CVS, subversion and perforce were built having a single server that contains all the versioned files and a number of clients that check out the files and a centralized server. Centralized VCS used to the standard for version control for many years.
Being centralized it provided everyone in the team knowledge to a certain degree of what everyone else on the project they are collaborating is doing and the administrator also have fine-grained control over who can do what. It is far easier to administer a Centralized VCS than it is to deal with local database on every client.
However, the advantages the Centralized VCS has for having a centralized server is also its major downside. A centralized server has a single point of failure. If the server goes down nobody will be collaborate or save versioned changes they were working on. Having the entire history of the project in a single server hard disk creates risk of losing everything if the disk gets corrupted. This issue is also faced by Local VCSs.
Here Distributed Version Control System steps in to resolve these problems
Distributed Version Control System
In distributed Version Control System clients don’t just check out the latest snapshot of the files from the server, they fully mirror a copy of the repository. Thus, even if the server dies for any reason, clients’ mirrored copy of the repository can be used as a backup to restore the server.
Moreover, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
There are many Distributed VCSs in use today, like Git, Mercurial and Bazaar, for people to collaborate and version control their projects without any hiccups and at their own pace.