Ivan's Space

Writing about leadership, management, emotional resiliency, software engineering, tech, gadgets.


I was fixing a couple of Audacious bugs and adding session management support when I first had to use the Mercurial source control management system and initially I quite liked it.

  • It’s fast, simple – comes with just enough commands
  • It’s consistent – one executable to rule them all, unlike GIT and its gazillion of executables.
  • It’s extremely easy to configure external tools for diff and merge, e.g kdiff3. For comparison in GIT merge tool is also as easy to configure, but there is no way except by an external script to set the diff tool. That’s mostly because most of the tools require 2 files to compare and not a patch.
  • Has Bash completion out of the box. GIT has bash completion, but at least on openSUSE I had to download “it” and add it myself.
  • It’s cross platform.

The initially spotted simplicity actually made me think it can help me to achieve the following work flow quite easily:

Branch for each (or at least bigger) feature/bug –> Work over time on the bug/feature and once it’s ready … –> Squash merge the bugfix/feature branch into the main one (merge as a single commit and also drop the branch’s commit history in order to prevent pollution of the main branch with private intermediate work) -> Drop the temporary branch

Now here comes my disappointment…

Even though Mercurial supports branches, the ones that can live inside the working copy (called “named” branches) cannot be dropped/deleted. Also squashing wasn’t supported, but cherry picking changes is via the shipped Transplant extension. So at the end of the day those long lived branches cannot be used for any temporary work. The short lived branches are in Subversion style – a clone in a different directory. Yuck!

Of course there are like 5-6 commands you can type in to do some magic to workaround this (delete a named branch), but I don’t like magic. Also there is an experimental 3rd party extension (not shipped with Mercurial) that provides  support for “local” branches. Experimental things to manage my code is not for me. And the last thing to mention is that Mercurial has decent built in support for patch queues, but again not much benefit work flow wise compared to Subversion. Also no good subversion “integration” is offered by Mercurial or its tools (only one-way).

Looking on the good side of things reading about Mercurial wasn’t a complete waste of time and due to its simplicity it helped me to get my head around new concepts very quickly.

For now I am very happy of what GIT has to offer me and the two-way Subversion “integration” via git-svn is great.

P.S: The Audacious/BMP/XMMS code is one of the worse I’ve ever seen. Looking forward to new Banshee.

Blog Logo

Ivan Zlatev



Ivan's Space

Writing about leadership, management, emotional resiliency, software engineering, tech, gadgets.

Back to Overview