Why we chose Mercurial and Bitbucket

Since the start of October we have been using Bitbucket to host the CloudEngine project. Almost as soon as we made the decision to use Bitbucket, people have asked why? So, I thought I’d reproduce an email I wrote to colleagues then. At the end I’ve noted how I feel about the decision two months on…

During September, I was tasked with deciding on where to host the free/open-source CloudEngine. By host, we mean essentially:

  • A repository of the source code (which basically keeps track of the ‘version’ of each file),
  • A way for developers to browse the source code repository online,
  • A bug and issue tracker,
  • A Wiki for documentation.

The provisional decision is to use Bitbucket, which uses the Mercurial distributed version control (repository) system (DCMS). I’ve summarised the reasons below.

The choice has been between:

Hosting the project at the OU was discounted early, as we wish to encourage the use, development and contributions to CloudEngine from the wider community. The three remaining contenders use two different version control systems, and which of the two to use – Git or Mercurial – has been a big part of the choice. Note that both Git and Mercurial are free/open-source and cross-platform software tools, with command-line and GUI alternatives. And the three hosting contenders are all free for open-source use.

To help in the decision I canvassed opinions from the Moodle and OU communities:

Some reasons to use Git (and Github) are:

  • Git is used for a lot of high profile and large projects including the Linux kernel,
  • Some projects that are interesting for the OU, Moodle and Drupal, have plans to migrate to Git (and the OU-VLE team in LTS plan to move to Git).
  • Git has the reputation for being flexible, powerful and fast.
  • Github has the most projects of the three platforms.

Some reasons to use Mercurial (and Bitbucket or Google Code) are:

  • Mercurial seems to have been designed with better cross-platform support in mind (Git was initially developed for Linux),
  • Where Git is a toolkit with about 146 sub-commands depending on the operating system (git –help –all), Mercurial is a cohesive ‘product’ with only 50 commands (hg –help). The large number of commands in Git would not be such an issue, if discussions and blog posts hadn’t pointed out that you start to need quite a number of commands for even a simple workflow. That is, Git may be complex for even simpler usage. (Eg. reprog.wordpress.com/ Still hatin’ on Git now with added actual reasons )
  • Mercurial has the reputation of having a shallower learning curve than Git – which relates to the point above.
  • Mercurial is written in one language (Python + C for ‘diff’), while Git is written in several languages
  • CodeIgniter, on which CloudEngine/Cloudworks is built, uses Bitbucket/ Mercurial (Pyrocms, also built on CI uses Github/ Git).
  • Bitbucket has more than 28,000 projects, so it isn’t small!
  • Plenty of respected projects use Mercurial/ Bitbucket/ Google Code, including Mozilla (Firefox), OpenSolaris, OpenOffice, Adium, Python (will migrate), Vim, Growl, Chromium (os Chrome browser)…

Some things to point out – these tend to level the “playing field” between Git and Mercurial:

  • It better to use any reasonably well-designed version control system, than none at all.
  • It is generally considered better to use one of the newer distributed systems like Git or Mercurial, than one of the old ones like CVS (eg. http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ )
  • CloudEngine is fairly small, when compared to Moodle and Drupal, and personall, I’d like to keep the “core” fairly small. So we don’t necessarily need maximum flexibility if there is a cost in complexity.
  • And I was concerned with getting the initial core developers – Richard, Juliette and myself up to speed quickly.
  • In the new distributed paradigm, there will be nothing to stop someone cloning our repository from Git to Mercurial or vice versa. And we can then pick up improvements, for example as a set of patches.
  • There will be nothing to stop anyone submitting patches, whether we use Git, Mercurial … (RCS!)
  • If sufficient numbers of CloudEngine developers use Git and we use Mercurial, we may at some future point provide a mirror of CloudEngine in Git. (And we may even move to Git – nothing is set in stone.)
  • And finally, I accept that as developers, we may well have to learn both Git and Mercurial to work on various projects.

It has been a hard choice, but on balance I propose using Mercurial. And I propose Bitbucket over Google Code as:

  • While Google Code is used for some large Google projects including Chromium, it is often used for the smallest projects – for example Javascript/jQuery plugins.
  • Google Code has the feel of a repository, while Bitbucket will hopefully be a community.

My links,

Two months on…

I have no complaints! On the Mercurial front, I find the command line tool easy to use, and there are excellent tutorials, references and books (online + print). There are some neat features:

  • hg serve – type this simple command to start up a basic web server, with configurable pull and push options.
  • Mercurial makes it easy to configure hooks to run on certain commands, for example commit and update. Git also has hooks, and I can’t comment on the comparable ease-of-use.
  • Syntax highlighting, progress… and other bundled and 3rd party extensions
  • Patch queues – I haven’t looked at these yet! (Mercuarial Queues Extension.)

Note, we have Mercurial on our Linux servers, courtesy of EPEL.

I’m fairly impressed with Bitbucket too. The wiki and issue-tracker are easy to use, with some useful macros, for example, <<issues query [format]>>. We have used the latter example on the Releases page in our wiki. It’s neat having the Wiki pages in a Mecurial repository. And the Mercurial support team are fairly responsive to queries and isuses.

If I have one slight criticism, it is, why have the wiki and issue tracker per repository? I expect CloudEngine to need at least one more repository for extensions and contributed plugins – as we won’t want a separate Wiki for that repository, we’ll need some fiddly links. And the links are generally longer. Anyway, these are relatively small points, and may be partially answered by considerations like the macro feature mentioned above.

So there you have it – no complaints, and use whichever platform suits your needs.

Watch this space for more on recent and forthcoming CloudEngine releases.

Advertisements

About Nick Freear

Author of Moodle 2 for Teaching 4-9 Year Olds, published by Packt Publishing. I'm in the Institute of Educational Technology at The Open University developing OU player, CloudEngine, Cloudworks, JIME... And, I'm into accessibility, HTML5, e-learning & internationalization.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

7 Responses to Why we chose Mercurial and Bitbucket

  1. Pingback: Tweets that mention Why we chose Mercurial and Bitbucket | CloudEngine Blog -- Topsy.com

  2. Jesper Noehr says:

    Glad you guys are happy with Mercurial/Bitbucket! Seems like you’ve made the right choice.

    A nice read, thanks.

  3. Andy Peters says:

    A good write up!

    I’ve been bouncing between git and hg for the last month. One day I feel like one is better than the other, then I wake up the next morning and have a different opinion.

    Anyway, I am curious how BitBucket is working for you in a (small/big/more-than-one-person) team. Who “hosts” what? Is it a crazy merging process? … just some thoughts here would be great… mostly related to BitBucket.

  4. Nick Freear says:

    Hi Andy,

    Thank you for the comment. We are currently a small team – just two developers.

    Bitbucket hosts the “master” CloudEngine repository, which is cloned directly onto our test and live Cloudworks servers (CloudEngine is the open-source code from Cloudworks). Each developer also has at least one cloned repository (I have three+, including one on my laptop!) I push to Bitbucket, and I have merged in code from the private repository of my colleague Richard Lovelock. He simply ran hg serve within our intranet.

    I have found merging fairly easy, and the overall process is working well. I’m looking forward to the day when we have contributors all over the world – a distributed community.

    Early days! Do get involved 😉

  5. Martin says:

    Wouldn’t it be awesome if the wiki software they use for the hg-backed wiki was open sourced, so you could install a local server that serves it, from the same repo?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s