I’d like to write a comprehensive book on revision control at some point. This is not even the start of that, but I’m going to record a few trends.
I’m going to cover the revision control systems that sprang to life as part of the BitKeeper debacle, because those are the most interesting ones to consider.
Monotone never really existed
Monotone was the template that both Mercurial and Git copied. However, monotone always followed a very purist model, and was dreadfully slow for many years. It caught up in speed somewhat, but has very few users.
Development is sparse, only a few commits in the past 6 months, and mostly bug fixes or translations.
Bazaar is dead
There have been no significant public changes to Bazaar in the past year. It’s been declining for years, and insiders admit that the focus changed from “Bazaar as a decent general-purpose version control system” to “ensuring that Bazaar worked well for package management in the Ubuntu project”.
There’s been some polite exchanges saying that many Bazaar architectural directions were superior to Git, but I have to disagree. The architecture of Bazaar informed the implementation, and the implementation is second-rate compared to Git or Mercurial. That said, some of the things Bazaar attempted were good ideas, and maybe those ideas can be transplanted somewhere else.
By “no changes”, I mean that there have been virtually no commits to Bazaar itself since mid 2012. There have been 7 commits in the past 30 days, 144 commits in the past year, and almost none of those are commits that will get released.
Some relevant links
Mercurial is slowing down
While Mercurial is doing far better than Bazaar, it’s growth seems to have been slowing down markedly. It has some big advantages, though: since it’s written in Python, the Windows client is as good as the Mac or Linux client. It has local revision numbers, which are far easier to deal with cognitively than hashes. Since it’s written in Python, it can be scripted in Python very reliably. It arguably has very clean and comprehensive documentation.
But it’s written in Python. It has a relatively weak branching model (so weak that cloning was the branching model pushed for many years, and cloning is not good for merging or comparing history). It doesn’t do rebase very well. And it’s getting new users at a far slower rate than Git, the emerging leader. And the rate of development of Mercurial itself is about half that of Git for the past 12 months. It’s of course moderately hard to compare a Python project to a C project.
Still, Mercurial isn’t dying. It’s perhaps more accurate to say that it’s reached its level. Fortunately, it’s fairly easy to go between Mercurial and Git. I predict that Mercurial will eventually completely lose to Git, largely because of the decision to use revlog approach instead of a blob approach. Blobs are more bookkeeping for moderate projects, but give more flexibility for large projects with lots of history.
One brilliant idea that was problematic in execution was Mercurial extensions. It’s super-easy to extend Mercurial with an extension. But then, you have a custom Mercurial install that you need to replicate to others if you need them to use your extension. Why not put extensions in repositories? Hmm, I should implement that change and push it upstream.
Git is taking over the world, although that might be due in large part to Github. While Subversion still seems to be the dominant open-source revision control system, most of that is inertia. Few new projects are choosing Subversion, and none are choosing CVS.
There are alternate implementations of Git. Github itself uses a Ruby version, and uses libgit2 for Github for Windows.
I need to analyse Git’s status more accurately, I’m an admitted partisan.
- no partial repository support (although you can permanently drop old history)
- falls down on gigantic repositories (10+ GB repository not pleasant)
- no good way to use multiple repositories together (git submodule is sub-par)
- no human-understandable version number
Veracity is a dark horse
SourceGear switched direction several years back and is trying to be a player in distributed revision control with Veracity. I read a lot of the book that was released, but I haven’t yet used Veracity. It hasn’t made much of a dent in the landscape yet, but since it’s very polished, it could get a lot of enterprise customers.
The impressive part is that it’s an open-source project, which is a big step for a company to take, but probably an essential one in order to compete with Git. So, since it’s open-source, it might survive SourceGear; not that SourceGear is in any immediate danger, but it is a project that’s being run by a commercial company, and those tend to live and die with the company.