The Mercurial Move

Six months ago Atlassian kicked off a big change in the way we develop software. In August 2010 we moved the Fisheye and Crucible source from Subversion to Mercurial. Since then the team has gained a wealth of experience and knowledge about distributed version control systems (DVCS) and we would like to share these with you through a series of blog posts. This, the first post in the series, explains why we decided to move from a traditional SCM system to a DVCS, and why we chose Mercurial.

So, why did we move to DVCS?

We want to kick ass and keep kicking ass.

• Modern tools for leading edge practices. At Atlassian we strive to be at the forefront of development practices within the industry, so that we can deliver awesome products to our customers. We have noticed a trend within the industry towards DVCS tools, particularly within the open source projects we use (e.g. jQuery, Adium, Raphael).
• Understand the benefits. All over the world people are talking about the benefits of using DVCS, and we wanted to know what we were missing out on. We wanted to better understand why development teams are moving towards these solutions, and to see if we can take advantage of the new development practises they make possible.
• Atlassians were already doing it. Many of our developers were starting to use Git and Mercurial for internal development via Subversion bridges (Git-svn and Hgsubversion respectively). They were seeing the benefits of DVCS, such as local commits, smart merging and offline work.
• Dogfood. We noticed that many customers are asking for better DVCS support within our products. Fisheye, Crucible and Bamboo already provide basic support for Git and Mercurial. But we feel there’s room for improvement, so that our tools fully support and build upon the distributed nature and repository structures of DVCS. By using DVCS tools ourselves, we can see what features we can build into our products that complement these tools.

Why Mercurial over Git or Bazaar?

Mercurial, Bazaar and Git are all awesome tools, but we had to choose one of them. After trying out the DVCS alternatives we decided to go for Mercurial because:

• We felt it had an easier learning curve than Git when moving from a Subversion background.
• Mercurial provides full cross-operating system support
• It comes with a simple set of base commands but powerful bundled extensions which advanced users can enable.
• It provides a great API for writing your own extensions using Python, a language which a reasonable amount of developers at Atlassian have knowledge of.
• It maintains a historical record of its branches and which branch a commit was made on. This can be incredibly helpful when trying to determine the context in which a change or bug was introduced.

Additionally we acquired Bitbucket last year. This came with 2 main benefits. We had a great hosting platform to store and fork our repository and the team came with a wealth of knowledge about distributed development.

Can you make the switch?

Moving the whole company over to Mercurial at once would have been disruptive and blown out the scheduling of many of our product releases. Instead, we chose to use the Fisheye & Crucible team as our pilot. There are a few things we took into consideration when choosing the team.

• Not too small, not too big. We had to chose a team which would be the least disruptive but also be to gain the most from the move. The Fisheye & Crucible team is a medium size team for Atlassian (between 15-20 developers), which meant we could keep the impact of the move to our release cycle to a minimum.
• Make use of expertise. The Fisheye/Crucible team could also be considered the SCM experts within Atlassian, having a deep understanding of the structure of many VCSs. That said, newer distributed VCSs (Git and Mercurial) were the teams weaker areas.
• Who needs its benefits the most. On top of that Fisheye is also the product within Atlassian which is most affected by differences in SCM models. We hoped that by using Mercurial ourselves, we could find the problem areas for Git and Mercurial repositories and create features and fix bugs associated with them. The branch selector we added in 2.4 is an example of such a feature.
• Branch and tag structure. The Fisheye/Crucible repository followed a fairly structured, industry standard layout for branching and tagging within Subversion compared to other Atlassian products. We initially thought that a non-standard structure would cause problems during the migration, but we have since found otherwise (more details on this to come).

What’s Next

Over the coming weeks we’ll be sharing more on our experiences of moving to Mercurial. The next blog will go into depth on how to convert your source repository from Subversion to Mercurial.