Blog

Intland now on Mercurial – Part 2: Transforming our tool set
Oct 13, 2009

This blog post is a sequel to our previous one titled Intland now on Mercurial. This time we write about what challenges we faced regarding the tools our developers use in their daily work.

In the server side

In the server side, we eat our own dogfood: since the very beginning, our primary collaboration tool when developing codeBeamer is codeBeamer itself. It has already been a brilliant tool to support working with Subversion since the first versions, but to be able to change to a coffee shop style workflow, codeBeamer needed several enhancements to add.
Just a couple of examples:
  • Parent-child relation of change sets was changed from one-to-one to one-to-many.
  • Event scheme used by our Managed Repository client (also known as scmloop) was extended with new event types: pre-update and post-update were added to pre-commit and post-commit. These wrap several commits as a single unit during a PUSH operation.
  • Git does not offer any built-in authentication mechanisms. Instead, using the ssh:// protocol is recommended if you need secure access to the repos. codeBeamer can now authenticate users by their SSH key pairs. In order to do this, users have to upload their public keys to their codeBeamer accounts, and use their private keys when accessing the repositories managed by codeBeamer.
We started to code these improvements several months ago, and we completed everything in the publicly available version 5.4. (You can grab the free version here.)

In the client side

The majority of our team members work using the Eclipse IDE. When we first started to think about moving to Mercurial, we were very happy to see that there exists an open source project to develop an Eclipse plugin for Mercurial. After a little research, it became obvious that the latest version of the Eclipse Mercurial Plugin was not sufficient to our needs, unfortunately. We might be somewhat spoiled by the convenience of Subclipse, but we wanted to keep our productivity during the change, or even to increase it if possible. For this, we’d need a similar same set of functionality from the Mercurial plugin like what Subclipse provides plus the benefits of DVCS, obviously, but it was simply not there.

What can you do then? This is where open source helps. In the next blog post we will tell you what we did, which direction we are heading, and we make an interesting announcement as well. Just stay tuned.

About intland

Provider of Agile ALM solutions. Father of JavaForge. Maintainer of MercurialEclipse. Into all things agile & DVCS. View all posts by intland

Leave a Reply

Your email address will not be published. Required fields are marked *

*


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>