How Version Control Tools Evolved

N.B : Writing about things helps me understand how things work end to end because it forces you to fill the gaps you have in your mind when you only think about things – I wrote about this here

There are so many version control tools available, the most popular one I would say is Git among so many others like CVS, Subversion, Mercurial etc.

I will be explaining the difference between the different generation of tools and how they evolved in this article.

FirstNoneOne file at a timeLocksRCS, SCSS
SecondCentralizedMulti-fileMerge before commitsCVS, SourceSafe, Subversion, Team Foundation Server
ThirdDecentralizedChangesetsCommit before mergeBazaar, Git, Mercurial

Table showing the history of Version Control Tools

First Generation Version Control Tools


No networking was available at this time , users had to login to the system (UNIX at the time) where the project was to work on it.


They implemented concurrent development with locks, meaning only one person could be working on a file at a time.


They worked only with files, they had no way of tracking changes in an entire project. Although it supported branching but the syntax was cumbersome, many people just used a single development branch with locking mechanism on files.

Second Generation Version Control Tools


They allowed projects to be hosted on a central server with all the branching happening on the central server usually via a server-client and was impossible to get the repository to your computer.


Working branch had to be updated before commit can be made. If user A and user B were working on the same branch and user A makes some commits and then user B tries to make his/her own commits, he/she gets denied because his/her branch is now out of sync and has to forcefully update and resolve conflicts on his/her branch before the commit can be made.


Commits were being done on files. It was however also possible to commit multiple files at once. This commit operation sends all the changes from the server-client to the central server.

Third Generation Version Control Tools


They allowed repositories to be distributed, this meant multiple users can work on the same project repository on their local computers and then can synchronise with another repository of the same project hosted on a server.


Commits could be made without syncing the local branch with the remote repository. This meant that user A and user B working on the same branch could make multiple as they wish on their local repositories and any one of them could resolve conflicts when merging to the remote repository.


Supported atomic commits affecting multiple files and thus creating a changeset. A changeset is a state of the whole repository.

References & Additional Resources