Version control used to be practically synonymous with CVS, but those days are well behind us now. In fact, you not only have an abundance of systems to choose from, you also have two distinct models of source code management to consider. In this article John Ferguson Smart test drives four popular open source version control systems and summarizes the pros and cons of each one.
Version control is a critical aspect of any software project, and its importance should not be underestimated. At the risk of sounding overly dramatic, the choice of version control system can literally make or break a build process. A good source code management (SCM) solution blends into the development lifecycle, seemingly a natural extension of the developer's tool set. A poorly adapted solution, on the other hand, can easily make life hell for the development team. At worst, it can be a powerfully dissuasive influence on good development practices such as refactoring, frequent commits, and continuous build strategies.
In the interest of excellent version control, this article introduces you to four leading open source version control systems. The veteran system is CVS, so I'll start with that, followed by its would-be replacement, Subversion. Next, I'll introduce you to Bazaar and Mercurial, two systems that take a distributed rather than a centralized approach to SCM. The actions involved in version control don't vary much from system to system, so I'll use a single example (the Java Petstore application from Sun) to walk you through common development scenarios using each product. I'll offer some observations about each, and then leave you to make your own decision based on what you've learned.
Before I delve into all that, let's review why reliable version control is crucial to the success of your application development process.
Why you need version control
Version control systems serve several key purposes. First of all, they allow you to safely store successive versions of your source code. In addition to providing a secure backup copy of the source code, this ensures you can back-track to a stable version if things go horribly wrong (which, as you likely know, they sometimes do).
Version control systems also help team members work simultaneously on a project's source code without stepping on each other's toes, or crunching each other's code. This can be done in several ways. One way involves locking a file when a user is working on it, so that other users cannot modify it at the same time. This is known as the "Lock-Modify-Unlock" model. The opposite of this approach allows developers to modify the same file simultaneously, and then merge the modifications into a new version containing changes from both developers. This second approach, known as "Copy-Modify-Merge" is more common in open source version control systems, because it is more aligned with the culture and practices of open source development.
Version control systems also help to identify particular versions (or revisions) of your project, such as a particular product release.
Finally, version control systems make it possible to create a new branch of your application source code, and work on this branch without compromising the stability of the original version. For example, you might release a stable version of a product even as your team continues to work on a parallel development branch. At a later date, you will integrate the changes into the main product branch and release a new stable version of the product.
Points of comparison
In the next sections I will introduce you to four version control systems capable of handling all the functions listed above. These products are too rich and complex to do justice to each of them in the space of a single article. Rather than attempt that, I'll use Sun's Java Petstore application example to take you through a short test drive of each of them.
The first thing you typically need to do with a version control system is add your source code to the repository. Next, you need to obtain a copy of the latest version of the project from the repository. Then you might make some modifications and update the repository. If another developer has simultaneously made modifications to the files there are two possibilities: the system could integrate the changes successfully, or you might have to resolve a merge conflict manually. At some point, you will want to identify a particular release by placing a unique label (or "tag") on that version. Later on, you will want to create your own separate branch of the code base, make some modifications, and then reintegrate the changes into the main branch.
To summarize, you can evaluate a version control system based on how it handles imports, exports, modifications, updates, merging, tagging, and branching. You'll probably also be interested in things such as ease of use, performance, and whether the system supports binary file types and atomic commits (which I'll explain later). In the next sections you'll see how CVS, SVN, BZR and Mercurial handle these steps, which should give you a practical idea of how each one copes in day-to-day use. It should also give you feel for which version control system best suits your needs.
For point of reference, you may want to download Java Petstore 2.0 before we begin.