Revision Control Systems

Be it a source code of some software development project or various writings for some publication in journal or conference proceedings, we inevitably create different versions of the documents or the source code. Instead of simply naming them as v1, v2.. or some scheme similar to it, there are many tools available which help us maintain different versions in a more efficient manner. Some of them mentioned here:

• Subversion (SVN) aiming to be replacement for Concurrent Version Systems (CVS). Both are based on client-server model.
• GIT: Fast Version Control System
• Mercurial: Distributed Control System
• Many others are mentioned here
• http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Both GIT & Mercurial is based on distributed peer-to-peer model, while SVN & CVS are based on centralized client-server model. A review of these revision control systems is presented in an article in Communications of the ACM Magazine, Sept 2009 issue. The main conclusions of this survey is reproduced here:
"Choosing a revision-control system is a question with a surprisingly small number of absolute answers. The fundamental issues to consider are what kind of data your team works with, and how you want your team members to interact. If you have masses of frequently edited binary data, a distributed revision- control system may simply not suit your needs. If agility, innovation, and remote work are important to you, the distributed systems are far more likely to suit your needs; a centralized system may slow your team down in comparison.

There are also many second-order considerations. For example, firewall management may be an issue: Mercurial and Subversion work well over HTTP and with SSL (Secure Sockets Layer), but Git is unusably slow over HTTP. For security, Subversion offers access controls down to the level of individual files, but Mercurial and Git do not. For ease of learning and use, Mercurial and Subversion have simple command sets that resemble each other (easing the transition from one to the other), whereas Git exposes a potentially overwhelming amount of complexity. When it comes to integration with build tools, bug databases, and the like, all three are easily scriptable. Many software development tools already support or have plug-ins for one or more of these tools.

Given the demands of portability, simplicity, and performance, I usually choose Mercurial for new projects, but a developer or team with different needs or preferences could legitimately choose any of them and be happy in the long term. We are fortunate that it is easy to interoperate among these three systems, so experimentation with the unknown is simple and risk-free."

More of this from the article here: Making Sense of Revision Control Systems, by Brayn O'Sullivan