Programming isn’t easy, especially when you are either doing a very big program, working with other people or programming in your spare time because you loose track of your work. And then the questions begin ‘Why did I do that?’, ‘Why is this commented out?’, ‘This function is no longer in the code? When did it get deleted and why?’ and many other, including the common ‘How was this before? Then it worked and now it doesn’t!’.
To avoid those questions and easily keep track of changes Source Control Management (SCM) and Versioning Control Systems (VCS) were invented. Long time ago I read a reasoning of how and why VCS appeared and the reason the latest paradigm in VCS called Distributed Version Control System (DVCS) had been such a success. It’s a shame I’m not able to link you to it, but I’ll try to summarize a few points.
If you are a developer you may have faced this kind of problems and you may have thought about a way to store your changes so you could go back in the development process and recover something you changed. Then, you would have periodically saved your sources into a folder, maybe named with the date or a keyword. Every time you had major changes, you would make a copy of your sources and store them in a new folder of that kind, let’s call it a snapshot. If at some moment you needed to go back in time you would just search for the appropiate folder and check its sources.
After some time doing that, you would start to add a file with notes like, what changes had been made, what were you thinking needed more work and other developer comments to each snapshot, let’s call it manifest . If you saved frequently snapshots you would easily end up without free space on your hard drive, so then you start to compress the folders to save up space.
This is a very reasonable solution, but it’s not really powerful, when it has grown a lot it’s very difficult to check the history because you have to manually inspect all manifests… Basically, VCS does that same thing, simply it’s been designed with tools to easy the search on history, to see diffs of your code and to share your repository with other developers.
Now you should start to grasp how important and useful are VCSs so let’s look at some and their types. We have mainly two VCS families, Centralised VCS (CVCS) and Distributed VCS (DVCS). The oldest one is CVCS like Subversion or cvs among many others and the most famous right now are DVCS like git and Mercurial. The main difference between CVCS and DVCS is that CVCS requires a central server to be accessible to a client for the client to review history or add changes while DVCS works stand-alone.
Why this difference? It may not be obvious but sharing a repository between developers may arise lots of problems. A simple example would be the following: Alice and Bob are working in the same project together and they both have the last copy of their codebase. Now, Alice is working at the same time as Bob, they are working on the same files and doing changes, maybe even to the same file, and they both want to submit their changes. Which changes should the central server accept? If Bob submits his changes before Alice, what happens when Alice wants to submit hers? This tricky question may be solved in various ways but it’s different to solve it in a centralised server than to solve it in every repository inside every developer’s computer.
This is all for now. I want to add that I personally chose git and I’m fond of it, and recommend you to use it if you are based on a Linux development environment. Other platforms support for git isn’t usually as good. More another time.