Well now that you all know all about what revision control actually is, I’m going to discuss why it should be used. What is the benefit to using a specialised piece of software that I have to learn how to use rather than just zipping up my files before I make the risky changes. There are number of benefits, each which will have an effect on how you perform your everyday operations. Now it is important to note, that this will have an increase in everyday work, this won’t reduce your productivity as the software will normally integrate with your current development environment.
First and foremost is the benefit of having a working set of backups, like any backup strategy this relies on it being implemented (more on this later), however the major purpose of revision control software is it’s capability to store a set of working backups that are created not regularly, but at the developers whims. This means that hopefully, each revision in the repository should be a working copy, or at least was intentionally stored.
Equally as important as the existence of the backups is knowing where they came from, who made those changes, and probably what crack they (or you) were smoking when they committed those changes. This comes from an important feature of being able to leave a comment as you upload changes, what is left in this comment would normally be left as a policy decision to the team. Normally, the reason for the change (ie. issue number) and any important information that won’t be blatantly evident to the next person.
Along similar lines, being able to see the difference between 2 versions of your project provides an extremely useful information and context which helps to answer other regularly asked questions, “When was this broken?” and “How was it broken?”. Most version control systems will provide you with a diff file, at the very least and most development environments which support a RCS will give give you a pretty view of this. This means that for any moment in the past, you can find out what a particular file looked like, and what it looked like in comparison to what it is now.
Originally, CVS was designed so that a team could work more effectively on a project, and this is possibly it’s greatest benefit now. Revision control systems introduce a concept called a working copy (more on this later) which is essentially a copy of the whole project. This copy is not the official copy but for all intents and purposes it is the project. This working copy usually stores (in hidden folders) information on it’s relation to the official copy. Each developer has their own working copy, so doesn’t have to worry about saving over another developers changes as the copies are completely independent of each other. Changes are then synchronised back to the central repository and any conflicts are brought to the attention of whoever causes the conflict.
This might all sound like crazy voodoo however in practice it is really quite simple with the correct tools. Most development environments either support or have plug-ins to add support for RCS. For example, in my environment of choice, Eclipse, I can check in with a single right-click, right a comment and click Commit, similarly with checking out a working version or comparing to an existing version.