A brief history of Version Control Systems
If you are a software guy, I’m sure you have worked with at least one version control system. There’s a high chance that recruiters ask you about these systems in technical interviews.
First of all, Git is the only VCS I’ve worked with and I think it’s the most famous and common one right now. Some people start learning Git before knowing what VCS is or how it works! So in this article we take a look at the concept of VCS and then a brief history of it.
What is a version control system or VCS? It’s a system that records changes to your files or projects and you can recall a specific version of your files later. It means that if you mess anything up, it’s easy to recall previous versions with VCSs. Of course if you are in the process of development and want to get back to a certain state of your project to check something out, it’s totally possible! I guess by now you know why it’s called version control!
I should point out that version control can be used in any industry. You may notice that even some graphic designers or UX designers need version control for their work flow. But the term “version control” is very well known in software industry and as a developer, I’d like to bring you an example in an IT environment.
Imagine a world without VCSs. A development team is working on a project. They use USB flash drive during the day to give their teammates the latest update on the project. A developer is working on a special part of the project to develop an important feature and wants nobody to work on it. At the end of the day a code conflict occurs and they should spend some time to resolve it. No need to mention if something blows, you don’t know whom to blame! So version control is very important for teamworking.
As previously mentioned, Git is the most famous VCS in the world which was introduced in 2005. But what was it like before 2005?
Ok! The easiest way is to copy your files in different local directories. Maybe this was how people used to control their files in the past. But this approach is very error prone as you may copy your files in a wrong directory or make other kinds of mistake which makes it hard to recover. Early programmers solved this problem by implementing Local Version Control Systems. Local VCSs have a simple database that keeps all file changes.
One of the oldest systems is RCS(Revision Control System) which was written in C and introduced in 1982. RCS is a part of the first generation of VCSs. It’s a set of Unix commands that keeps patch sets(which means differences between files) and makes it possible to recall older versions of files.
Local VCS is not good enough for teams. This leads us to the next generation of VCSs which is being called Centralized Version Control Systems. Tools like CVS (introduced in 1990), Perforce (introduced in 1995) and Subversion (introduced in 2000) are an important part of this generation. In these systems we have a central server which contains all versioned files and developers can connect to that server. This approach is better. Administrator can monitor people and team members can see what other members have done. But it has a serious downside which is single point of failure. If the server goes down or the hard disk the central database is on becomes corrupted, we get into trouble.
To deal with this issue, Distributed Version Control Systems step in. Bazaar, Mercurial, Git and Darcs are the most notable tools of this generation which were introduced around 2003 to 2005. In Distributed VCSs, each user mirrors the repository, including its full history. With that being said, it means every clone is a full backup of all the data.
This was a brief history of VCSs in the past 30–40 years. Now let’s take a look at another brief history!
As we know, Linux Kernel is one of the biggest open source projects in the world of software engineering. In 2002, the Linux Kernel project started using a VCS called BitKeeper. In 2005, the community of Linux Kernel developers and BitKeeper were not on good terms and their license was revoked. That was how the community of Linux Kernel developers started developing their own version control system based on their experience with BitKeeper and that was how Git was born:)
That’s it! I got my ideas for this article from ProGit book. I highly recommend you to read it if you are willing to learn more technical stuff about Git.
