Successor to CVS? Subversion ain't it!

For the non-Eclipse-committers out there, there's been an interesting conversation proceeding on the committer mailing list. Since it's off-topic for the list, I'm replying on my blog.

On the mailing list, the question was:

The answers ranged from:

• Fix SVN by writing better tooling around it. (The Subversive tooling folks kindly reminded us of their newsgroup and bugzilla).
• Just use CVS.
• Switch to something better.
• Write poetry about our frustration with SVN. (I'm not kidding; one person posted his poem.

A year and a bit ago, I contracted with a company that does not allow SSH through the firewall. So I was in the market for something that:

• Allows version control over HTTP.
• Has a decent Eclipse plugin.
• Has traction, particularly in the Java community.
• Is well-supported on all platforms Java developers use, particularly Windows.
• Is not Subversion.

It turns out that with only minor caveats, Mercurial fits all of these qualities today for the work that I do.

Mercurial can expose a repository through a regular HTTP web page using CGI or Fast-CGI. It uses regular old HTTP post, so if the site is accessible, version control Just Works. The same web site that exposes version control also automatically doubles as a ViewVC-style web interface to the repository. Sweet.

This makes server-side security really easy too, since you can use HTTPS and Apache authentication to secure the repository and don't have to give out full SSH logins to people you barely know.

When I started, Mercurial's plugin was usable, but barely so. Today, it is fully featured, but needs another 3 months of hard usage in the wild to get all the last niggling bugs out.

But I've been amazed at how quickly the Mercurial Eclipse plugin has progressed. It's really a nice piece of software and I trust it with my day-to-day work now.

Mercurial is the only distributed version control system to be widely used for large Java projects. In particular, the large Sun Microsystems open source projects like OpenJDK and NetBeans now use Mercurial.

Outside of the Java space, Mozilla.org has standardized on Mercurial for their version control.

With large customers like these, we can be assured that Mercurial will be well-supported for years to come.

Mercurial is one of the few distributed version control systems that runs as well on Windows as on Unix-based operating systems. Since the vast majority of Eclipse users run Windows, this is important.

Over the past 6-9 months, I've been using Mercurial more and more exclusively for new development.

• Initially, the Eclipse tooling was a bear to work with. But the Eclipse tooling has now stabilized and has become (mostly) a joy to use.
• As mentioned above, Mercurial has been a joy to work with on the server side.
• On the client side, I've gotten addicted to always having instantaneous access to my full repository history even when I'm on an airplane, because it's always on my local hard drive.
• As everyone says, branching and merging is much easier than with CVS or SVN…
• I love how Mercurial doesn't spatter .cvs or .svn-like folders all over my repository. Rather, there's one .hg folder in the root of the repository. This makes searching my repository from the command-line or Windows Explorer easy again.

Someone will ask, “Why not Git, or some other DVCS?”

The answer is simple:

1. To my knowledge, Mercurial is the only DVCS with a mature Eclipse plugin.
2. Mercurial is the only DVCS used widely on very large Java open-source projects.

For this developer, Mercurial has proven to be everything I've wanted in the near term. From what I've seen so far, I could also imagine it being a good choice for Eclipse in the long term.

~~LINKBACK~~ ~~DISCUSSION:closed~~