3.7 You have started using a version control system that's actually good.

The main criteria here being that whatever system you decide on it must: make branching and merging feel almost trivial to you, have a command set that's easy and flexible, and allow multiple people to work on the same file at the same time. If your system can do all that and you and your coworkers are happy with it then don't change.

I'm going to stick my neck out here and suggest that you really ought to be using a distributed version control system. I don't care if you have a development team of one or one thousand. Traditional version control systems that work like CVS and Subversion are good. But, you're missing out on some truly great features if you stick with them.

The leaders, at the moment seem to be Darcs http://www.darcs.net, Git http://git.or.cz/, Mercurial http://www.selenic.com/mercurial/, and Bazaar http://bazaar-vcs.org/. Darcs has the advantage of a very well thought out set of commands, each with an corresponding undo. Git is being used to manage the Linux kernel and has some significant performance benefits. Mercurial is being used for the open source version of the Java Development Kit. Bazaar is being used to manage the Samba project but not much else of note. They're all conceptually fairly similar but each has taken a very different approach in their respective implementations. Darcs is written in Haskell, Git is written in C and leverages a variety of shell scripts, which means it doesn't work very well under Windows, and Mercurial and Bazaar are written in Python. All have Eclipse plug-ins in various stages of development.

It was my intent to discuss all the reasons that distributed version control systems are great here, but it turns out I've already discussed the feature that I find most advantageous above: branching. And, Mark Reinhold[2] has summarized the high-points quite well with this:

• A branch is just another repository, not some state in a central database. You can create branches at will to explore new ideas and, equally easily, simply delete them if things don't work out.
• You don't need to be connected to a server - or even be on the network - in order to get work done [and still take full advantage of revision control].
• You don't need to set up and manage a central [VCS] host with sufficient disk space, compute power, bandwidth, and backup to support the concurrent [VCS] operations of your entire development community.

One of my favorite features of distributed VCS systems is something I've never seen explicitly mentioned, and that's the fact that branches are self evident. In CVS branches are kind-of mixed in in some non-obvious way. In Subversion they're additional folders that are only differentiated from the main branch by the convention of putting them under a folder called ``branches''. In a distributed VCS you'd generally have a folder for each project you were working on and each folder within that would be a branch. As with any VCS it's assumed that you'd name them in some useful manner.

Something Mark doesn't mention is the huge advantage a distributed VCS has for open source projects. If Mozilla has taught us anything it's that you're not going to get thousands of developers working on your project. So, while huge numbers of developers is something that distributed VCS handle exceedingly well it's pretty much a moot point. In my experience, a developer interested in some OSS (Open Source Software) project will download the source from a traditional VCS, poke around to understand it, and, if they're smitten with the idea, start customizing it for their needs. But, they are forced to either work without the benefits of version control or they have to check it into their own personal VCS. If they check it into their own the projects main developers can pretty much forget about ever getting patches from them because they're no longer able to sync with your tree and it would be way more work than they generally want to do to get synced and give you a patch that was useful. If they work without VCS (because they don't have commit rights to your VCS) they may send in a patch but the work to get there has been like climbing a rock face without lines and harnesses.

If the projects developers were to use a distributed VCS each developer would be working off of their own personal copy of it that could be synced at any point in time no matter how many changes, revisions, or commits they have made. They're generally not going to check it into their own VCS system because that's work that doesn't get them any real benefit because they already have version control via their checkout and the fact that it's a distributed system. The end result is that they don't need to work without the safety and security of an VCS and they will generally always be working on a system they can easily send you changes from when they're ready.