Ben Collins-Sussman, one of the key developers behind Subversion, argues in Version Control and the 80% that distributed version control will remain a niche interest, and will not move in to the mainstream (as his favorite tool certainly has). He has a number of good reasons to back up this thesis.
I think he’s wrong. The “other 80%” are not profoundly stupid imbeciles who could never grasp the point of DVCS. Rather they are, generally, working developers with important projects underway, for which they need tools to work well out of the box when used in the default way. DVCS tools can certainly do that. More specifically, the list of reasons he gives why DVCS won’t become broadly popular, should be read more as a to-do list of how to improve DVCS so they can become broadly popular. What the DVCS community needs is at least one DVCS which:
- Installs easily on Windows, with a single installer, including diff/merge tool and GUI
- Includes a very good standalone GUI
- Secures client/server (peer-to-peer) communicate by default, without user setup of SSH, HTTPS, etc.
- Integrates well with Eclipse
- Integrates well with Visual Studio
- Integrates well with Explorer (i.e. TortoiseBlah)
- Integrates, begrudgingly, with Microsoft’s SCC API so as to support the many tools which can use an SCC API plugin
- Includes permission controls for server repositories, including good tools for configuration thereof
- Automates sharing of branches trivially (some already do this, some less so)Automates the common ways of using a DVCS, most importantly the usage model in which the DVCS is used as a better SVN with full offline capabilities
- Guides users, if so configured, gently back toward a small number (one, in some cases) of main central branches, which is what most projects want
- Communicates clearly what kind of project it can support well (most of them) and what kind it won’t support well (those with an enormous pile of huge files, of which most users only need a few)
(SVN itself is not without flaws. Ben lists some of them as areas in which improvements are coming, while others (such as, in my opinion, using the file namespace for branches and tags) are likely here to stay.)
In the next few years we will probably see one or more DVCS tools gain most or all of the features above. With addresses, an important truth will be more obvious: distributed source control is, in most ways, a superset of centralized source control, and the latter can be thought of as a special case of the former.
That said, though, I think the DVCS movement will lose a bit of steam when SVN ships better merge support, if that merge support is sufficiently good. The merge “features” are certainly the biggest issue we have here with SVN.
Very few people (as a percentage) use ClearCase. It is slow, buggy, user-hostile, and really expensive. Yet, it has the right idea for the long run. Version control should be a painless automatic consequence of a versioned file system. Time machine in Leopard may mean that fewer single developer shops need version control. The same is true of ZFS in Solaris. Actually, the version control build into Eclipse meets almost all of my needs.
In the long run the file system will take on enough database features to greatly reduce the need for databases, too. But that’s not so close to happening.
I have used ClearCase; and I found it to be amazingly slow and user-hostile. Those could be fixed. It might then be the right solution for you, for the problems you face. For me however, the “versioned file system” metaphor is not the right path. Even a totally fixed ClearCase would not be good for me; for me a magic file system, no matter how bugless, would be undesirable. The whizbang automatically-up-to-date CC “view” idea is amazing technical achievement… but not one I want.
A lot of the claims that Ben made about the “other 80%” are consistent with my on-the-job experience, and while I don’t believe that my co-workers are “profoundly stupid imbeciles who could never grasp the point of DVCS”, I can attest to the fact that it’s often a struggle just to get them to use Subversion consistently. It was interesting, however, to read that the Subversion team is looking at integrating some DVCS features into Subversion 1.5. There’s no question that Subversion’s support for merging is fragile and error-prone.
There are some hilarious parody videos of Accurev and Clearcase on Youtube. But the main reason for my comment was that I too began using SVN for home projects and since Accurev provided me an AccuPass 2-user license, I switched to it. No question the merge capabilities are way better than SVN and more naturally obvious, but I don’t think even when completed the merge capabilities in SVN will be adequate for most users.