Switching to Mercurial

A distributed version control system makes and merging significantly easier. In other words, simplifying these two things makes it significantly less time consuming to work on 1.4.1 while also working on 1.5; sharing changes between two separate branches is often a problem.

It took a lot of debate, though not all that recently, for us to finally decide to switch to Mercurial for our version control needs. I’m really enjoying it so far; it’s fast, it’s efficient and it’s easy to grasp. There’s a few issues we’ve run into, but hopefully we can figure out solutions. Right now the main concern is the fact that our binary copy of libpurple in the source code is significantly impacting the size of the repository.

You can now find our Mercurial repositories at We’ve written up a small amount of documentation so far on acquiring the newest Adium source and on getting Mercurial. The latter is very, very easy on Leopard, and slightly harder on Tiger. Our repositories are, as always :), being hosted by our awesome friends at Network Redux on a new server setup we’re getting ready to use.

The great part about using a distributed VCS is that every single person’s copy of the repository is a full-fledged copy of the repository; the only difference between the server’s repository and yours is that the server has scripts set up to trigger events, and it’s a trusted source for nightlies and other fun things. This makes it very easy to continue development during or recover from a significant server outage. Should the worst occur, we could easily restore our server records based on developer repositories, if need be.

To that end, I’m happy to say that our two main repositories, adium (currently 1.4) and adium-1.3 (1.3.x development) are now mirrored hourly at Bitbucket, a service which quite a few of our developers use for their personal source code needs.

Our old SVN access is now read-only; all information on our SVN server is now available through our mercurial repositories, except one or two insignificant, non-working plugins. No future commits will occur in SVN (in fact, trunk and branches/adium-1.3 currently have #errors in them to intentionally prevent use), so you should transition anything that uses them over to Mercurial. Enjoy. 🙂


  1. Would be interested in hearing why you went with hg over git. Is it primarily because of Bitbucket over Github, or is it about the hg and git implementations themselves?

  2. Mostly because our developers don’t like git. One or two have been using Mercurial personally (or even hacking on things, like durin42’s hgsubversion) and pushed us away from git. I was kind of apathetic, git does have smaller repositories, and can be a bit faster. Mercurial has some fun things, like per-repository revision numbers (SUPER useful for nightly builds). It’s also less a file system and more a version control system.

  3. It’s easy to generate per-repository version numbers in git, just ‘git rev-list HEAD | wc -l’.

  4. astrange: Or, in Mercurial: hg log –template=”\n” | wc -l. There are a couple other ways; we’re using hg id -n and stripping off the possible +.

    At least two of us actively *hate* using Git. Speaking for myself, I have tried it (in working on ClickToFlash), and I liken it to managing history by hitting yourself in the face with a meat tenderizer. Mercurial, on the other hand, makes me happy.

    Much of it is probably impedance mismatch: Git uses different terms for some things, and the same terms for different things, so we’d need to learn it as if we’d never used version control before. Screw that—it would take longer. We switched to Mercurial in about a day, plus another day for secondary things like Buildbot and commit emails. We are already back to working on the Adium code. We couldn’t have done that with Git because of its learning curve.

  5. I think this is a mistake. Regardless of technical merit, for the shear reason of market share, I think Git should be used instead. The number of outside contributions to the source code would skyrocket rapidly if put on GitHub.

  6. Adium isn’t really the type of project where you can jump in, fix something, and push a patch. That is, it’s not small enough that it’s a quick job. In either case, you can download the source to Adium very easily from hgweb; there’s nothing stopping someone from fixing an issue and sending us a patch. I don’t think merely using git, or merely posting on github, is itself going to affect contributions.

    As a *Mac* program, the argument of market share, I gotta say, isn’t something that works here.

  7. Rich: Saying that Git should be used because of market share is a very weak argument, especially among this community. After all, the same argument could be used to say that Adium should be developed for Windows instead of for the Mac. In addition, I doubt that its presence on GitHub would have any significant impact on Adium’s exposure among potential developers.

    The fact that some of the devs were using Mercurial, at least two *hate* Git, and that Mercurial is closer to SVN’s terminology are strong arguments for Adium using Mercurial over Git. The real issue here is not to follow the crowd, but to select the best tool for the job. Choosing a tool that’s better than the previous (SVN), that some developers are familiar with, none of the developers hate, and without a steep learning curve are all properties of such a tool. If a tool that doesn’t fit those criteria, then it is an argument for a different tool, or not changing at all.

  8. Rich: “Regardless of [how badly it sucks or how much better Mercurial is], for the shear[sic] reason [that more people use it], I think Git should be used instead.”

    That’s how your statement reads to me.

    I contend that Mercurial being so much more pleasant to use outweighs how many more people use it.

  9. Git fans: The time to speak up about Git & why it’s awesome is not now — it was months ago when we were making this decision. See for more information about how to be involved in decisions like this, or getting involved in other ways. Also note that like many open source projects, the opinion of the people doing the work is more important than the opinion of observers.

    To put it another way: Does the switch to Mercurial impact your contribution to Adium? Do you contribute to Adium?

  10. Zac,

    The link to the 1.3 branch mirrored with us contains an extra “.”. The link 404’s 🙂

  11. @Jesper – whoops, fixed. Thanks.

  12. Do you plan to install the mercurial plugin for Trac, so that Trac can be used to view the source, commit history, etc again?

  13. Yes. Though for now you can use hgweb, which is much much faster than Trac ever was –

  14. I think you all made a good decision going with hg. Congrats!

  15. As a git & svn user I had no problem installing Mercurial and compiling the latest Adium build. Remember that the core developers should be able to use the tools that works best for them. Getting Mercurial is a simple job – there are even binaries for OSX if you are not comfortable compiling: It is * only * SCM and if you don’t contribute to the project what difference does it make anyway?

Post a Comment

Logged in as - Logout