Thread: The need for revision control

If you've ever worked on a complicated project, you will surely understand the benefits of saving multiple copies of your work in progress. Imagine working on your history project for weeks, only to realise that the original introduction would fit in better. Without backups at multiple stages - you're helpless.

Often we accomplish this by repeatedly saving the file with a different name, hopefully with some kind of patter such as "HistoryProject-v l.doc", "HistoryProJectv2.doc" or "HistoryProject-20090615.doc". However, over time this will surely create a mess.

The problems complicate even further when you have multiple people working on the same project. How do you reconcile the barrage of changes that a team can inflict.

It may seem simple to have the file hosted on a shared server where everyone can access and modify it. However, if everyone were to save files affixed with their name and timestamps, you would soon end up with an unmanageable mess of files of which only a few will ever be of any use, and many changes will be lost as people will use outdated revisions of the file and build on those.

Wouldn't it be great if your file system itself could store each change separately? Such that it would be invisible until needed? Many such file systems indeed exist (ext3cow, wayback, tux3 etc). However a simpler solution, which doesn't involve shifting to *NIX and messing around with kernel modules is to use revision control software.

We can categorise revision control systems based on how the system manages its repository of data, and how it manages to avoid conflicts.

Two approaches to resolving conflicts as multiple people try to modify the same file at the same time are the lock-modify-unlock model, and the copy-modify-merge model.