Since we began offering Mercurial support and consulting in 2010, aragost Trifork has been involved in a number of projects. Below we have described some of the more interesting ones.
CVS to Mercurial Migration
At the end of 2010, the University of Zurich decided to migrate their online learning platform (OLAT) from CVS to Mercurial. Upgrading their version control system was a necessary first step that would enable them to begin refactoring their code: the refactoring would involve massive renaming in multiple concurrent branches and they needed a system that could handle the merges. In addition to its robust merge support, Mercurial was selected because of its ease of use and good and its robust support for merging.
aragost Trifork was contacted early in the process in order to get advice on the future repository layout: How would changesets flow between feature branches? Should they use named branches or multiple repositories? How to support older releases and how to ensure the quality of released code? How do we handle maintanence of old releases?
We worked with them to define a workflow based on multiple repositories that allowed them to stage and test feature branches internally before publishing them to the wider community.
The 15 developers were trained over two days (a full day for the back-end developers, half a day for the front-end designers) in order to get everybody up to speed quickly on the new system. The designated Mercurial admin received an extra day of training with focus on server-side tasks.
After the migration, the team began heavy refactoring of their code. The first branches have already been merged effortless into the main line.
Workflow Advice & Custom Extensions
We have helped a major German client with their migration from ClearCase to Mercurial. They migrated several hundred developers over the course of several months.
The migration faced some unique challenges since the client works with very big repositories. Their software is heavily modularized and so they naturally looked to Mercurial’s support for sub-repositories in order to split the repository into smaller components. However, at the beginning of the migration process, Mercurial had only rudimentary support for sub-repositories. The client contacted aragost Trifork with a proposal for improving the sub-repository support and Martin Geisler worked with the Mercurial community to get the proposal accepted. This was crucial for the client: they did not wish to take over the continued maintenance of this feature.
Another feature requested by the client is support for locking files in a central repository. Mercurial does not include any support for locking files since this goes against the grain of a completely distributed system. However, when files cannot be merged (Word documents, FrameMaker files, PhotoShop images, etc.) it does make sense to lock them in order to prevent accidental concurrent work.
A new lock extension was therefore designed and implemented. The extension will start out as a third-party extension, but the hope is that it will eventually become a standard extension shipped with Mercurial.
Two-Way Mercurial–Subversion Bridge
Since a version control system is a crucial part of the infrastructure, companies often want to migrate in small steps. We were contacted by a Canadian client who faced this problem: 150 developers were busy adding features and fixing bugs, and yet they needed to migrate to a new system in a smooth way.
The need to migrate was caused by a desire to have better merge tracking. The client has a large codebase with several deployed releases that must be supported in parallel. When a bug is fixed on one branch, it must be merged downstream into other affected releases. This is where Mercurial shines: merging bugfixes from one branch into another is easy since Mercurial tracks all changes accurately, even across renamed files.
To ease the migration, aragost Trifork developed an automatic two-way bridge between Subversion and Mercurial. A daemon runs on a server and continuously synchronizes the two worlds. New files on the Mercurial side are added to Subversion and committed, and likewise for new files from Subversion. When files are renamed, the rename information is also propagated — this is important to ensure that future merges can take advantage of the rename information.
In addition to the generic two-way bridge functionality, special merge logic was built into the bridge. This concerned some directories where a merge should always be one-way: any changes from branch X should always win over changes from branch Y. Mercurial does not support such per-directory merging by default, but we were able to handle this with a little scripting.