mercurial usually shows inactive branches when running "hg branches" but that's kind of annoying if you have lots of old inactive branches. So I recently set up my personal .hgrc to hide inactive branches by creating an alias.

[alias]
branches = branches -a

Normally you get this kind of output.

ian@laptop:~/src/prj$ hg branches
default                     1662:1fa310d3052a
hoge                        1661:62d737e7146e
hoge_inactive               1623:ba27ba59a257 (inactive)
hoge_closed                 670:1c3134ca4a95 (closed)

But after setting up the alias inactive branches aren't shown.

ian@laptop:~/src/prj$ hg branches
default                     1662:1fa310d3052a
hoge                        1661:62d737e7146e

This way though there isn't a good way to show all branches if you have set up an alias so you might want to give the alias a different name like "abranches" for "active branches" so that you can show all branches by using "hg branches".

Recently I've been forking svn repositories by converting them to mercurial repositories and uploading them to bitbucket. It's fairly easy with the mercurial convert extension. Convert is distributed with mercurial so if you have a recent version all you should have to do is put the following in your hgrc.

[extensions]
hgext.convert=

Converting a repository over http by running convert using the repository url can be very slow so it's generally much faster to sync the svn repository locally and then convert it to hg. First you need to use svnsync to copy the repository.

$ svnadmin create foomirror
$ echo '#!/bin/sh' > foomirror/hooks/pre-revprop-change   # make insecure dummy hook
$ chmod +x foomirror/hooks/pre-revprop-change
$ svnsync init --username svnsync file://`pwd`/foomirror https://foo.svn.sourceforge.net/svnroot/foo
Copied properties for revision 0.
$ svnsync sync file://`pwd`/foomirror
Committed revision 1.
Copied properties for revision 1.
Committed revision 2.
Copied properties for revision 2.
...

Once the mirror is set up you can run hg convert on the local mirror. This turns out to be much faster than trying to convert the svn repository remotely.

$ hg convert foomirror   # convert directly from repo mirror to foomirror-hg
...

I recently started using mercurial's mq extension at work as I found myself switching between changes a lot. I often had to set changes I was currently working on aside to do a merge or fix something that was more urgent. The mq extension makes that possible by managing patches and allowing you to put away changes into the patch queue.

mq is included in mercurial's distribution by default but you need to enable it in your .hgrc

[extensions]
mq =

Ok, so now I'll run through the most used commands.

hg qinit

When you want to create a new patch you use the qnew command.

hg qnew

My original use case for mq was as a place to put my current changes so I could do back to a normal state and do some work without actually having to commit it to the repository. Originally I thought that because qnew spit out errors when I tried to create a new patch, I figured I would have do the following in order to get it back to a normal state and create my patch.

hg diff -U > my.diff
hg revert --all
hg qnew mypatch
patch -p1 < my.diff

But a friend informed me that the -f option to qnew does exactly what I needed. It takes your current changes and then rolls them into the new patch.

hg qnew -f mypatch

The patch shows in your revision history while it's applied but it's not really committed.

After you make some more changes you can update the patch by running qrefresh.

hg qrefresh

You run qrefresh with the -e option to set the commit message that is used later when you actually commit to the repository.

hg qrefresh -e

Once you set it you can just run qrefresh without the -e and it will retain the message.

Here's the fun part. If you need to put the changes away you can unapply them off by running qpop with the name of your patch

hg qpop mypatch

or qpop -a which unapplies all the patches.

hg qpop -a

This will bring you back to the normal repository version. You can then merge or fix a bug or do what you need to do. After you are done and you want to work on your changes again you can reapply them with qpush.

hg qpush mypatch

or

hg qpush -a

Mq doesn't care about the revision history so you can try to apply the patch anywhere in the revision history. Be careful though since the patch might not apply if there were changes to the files updated by the patch.

Once you are done with all your changes you can run qfinish to commit them to the regular repository.

hg qfinish mypatch

You can call it with a range also. MQ gives you qbase and qtip labels which are attached to the base patch and the tip patch. This effectively finishes all the patches.

hg qfinish qbase:qtip

That's it!

So for the longest time, well, about 5 months, I have used the mercurial package in cygwin as my mercurial at work where I run windows on my desktop. I use cygwin as my terminal on windows because it's unix like and window's command line is a piece of shit. No sane command/path completion nothing. Scripting is a nightmare etc. Anyway, the reason I used it was because I was under the false impression that all other mercurial installations wouldn't play nice with unixy paths.

Well, I was wrong. The hg.exe that is shipped with TortoiseHG deals with the paths, at least relative paths, nominally (Though, I'm sure something like cygwin's silly /cygdrive/c/file.txt wouldn't work). So I've been using cygwin's mercurial with TortioseHG's hgtk and kdiff3 for a couple months under the silly, wrong assumption that the hg.exe would junk my paths. oh well,

Uninstall the cygwin mercurial package and put TortoiseHG's path in my PATH environment variable (well it was already there) and everything's dandy. TortoiseHG just magically works on windows (though mercurial repos on the windows network are sloooooow). It's nice to be able to just type 'hg push' and have it work as well as "hg merge" the same way I do at home on my linux machine ("hg view" is "hgtk log" though).

Mercurial is a nice distributed SCM system written in python which I have been using at work and at on oss projects for a little while now. Mercurial allows three types of branching, cloning, named branches, and local branches. Each of these has it's uses but I have only really used cloning and named branches in my own development.

Cloning simply allows you to create a new branch of a repository by creating a copy of it. Simple. You make a copy of the repo, make changes in that copy, and you can merge the changes back into the original branch using push or merge changes in the original into your copy using pull. This is by far the simplest way to do branching. Each branch is self contained and easily managed/copied/deleted (which may or may not be a good thing depending on how you see things).

Named branches are branches that live in the same repo. You can create a new branch make a commit, and switch back to the original branch all within the same repo. This is achieved using the branch command in mercurial. You can switch your branch like so:

hg branch mybranch

Here we just created a branch off of the current version and called it 'mybranch'. Now if we make a change and commit it this change will be marked as part of our new branch. This is kind of nice because we can switch between branches quickly and easily. Also, long lived branches can be split off within the same repo and merged easily using the merge command. You can switch between branches by updating your local repo with the following command:

hg update -C mybranch 

This command figures out what changes need to be removed and what needs to be added to get you to the HEAD of the another branch.

Unfortunately, this is where the good things about named branches end. Named branches live in the same repository so you can't selectively push or pull changes. So if you have a bunch of changes in your main branch that are ready for pushing to your shared repo, but you have a named branch full of changes that aren't ready to see the light of day, you can't selectively push the stuff in your main branch without pushing the stuff in your test branch. This is a big problem because it can clutter up your shared repo.

Also, the hgweb and hgwebdir cgi scripts that show you changes to your repository in a easy to understand way simply fail to break changes out by named branch. This was the biggest problem for me because I lost track of what changes I had put in what branch so I had trouble compiling all the changes I wanted to for a release. I really wanted to look at the web interface and see the changelog for a particular branch but the hgweb interface simply shows all changesets in chronological order regardless of what branch you clicked on. It also doesn't show what branch a change was commited to so it's impossible to find out where a particular change was commited without looking at the parent changeset and backtracking to where it was split off from the main branch (this is not reasonably achievable.

Named branches are also not deletable. Meaning once you figure out all of the downsides of using them your repository is already full of these named branches and you can't delete them. This also exasperates the push problem because you might push some changes in a test branch to a shared repo inadvertently but once you realize this the damage is already done because you can't delete the branch from the shared repo without backing out all of the changes you made, nor can you delete them from your local repo and then push, or selectively push only one named branch. Basically you're stuck with them forever.

This is probably why there has been talk on the Mercurial mailing list this month about fixing named branches and recommending that developers not use them until they are.

I just set up my e-mail settings with Mercurial so that I can e-mail patches via my Gmail account. I have Debian installed on my machine which has exim installed by default so it was pretty easy to set up. I'm not terribly versed at setting up mailing agents so I basically followed these instructions on the Debian Wiki. After getting that set up it's easy to set up Mercurial to use exim4 since it's a drop in replacement for sendmail.

To set up Mercurial to use exim I followed the instructions on the Mercurial Wiki:

email::
...
method;;
    Optional.  Method to use to send email messages.  If value is
    "smtp" (default), use SMTP (see section "[smtp]" for
    configuration).  Otherwise, use as name of program to run that
    acts like sendmail (takes "-f" option for sender, list of
    recipients on command line, message on stdin).  Normally, setting
    this to "sendmail" or "/usr/sbin/sendmail" is enough to use
    sendmail to send messages.

  Email example:

    [email]
    from = Joseph User <joe.user@example.com>
    method = /usr/sbin/sendmail

So here is my very simple ~/.hgrc file:

[ui]
username = Ian Lewis <IxxMLxxxx@gmail.com>
[email]
from = Ian Lewis <IxxMLxxxx@gmail.com>
method = /usr/sbin/exim4

Simple. Now I just enable POP for my gmail and I can use hg email and it will go through my gmail account. Now only if the Mercurial guys would fix this issue so I can send the patch email with the correct encoding.

Today I've been playing around with writing programs in GTK2.0. This has been on my todo list for a really long time, almost since college, but I've never got around to it. I've revived my old project gorbital and decided to rewrite it using GTK2.0. I originally wrote it in C++ using gtkmm for GTK1.0. But GTK1.0 is long since dead. Even my beloved Gnucash has finally made it to the world of GTK2.0 making it the last application I use that has made the switch (gaim being the first).

The documentation here and the tutorial here are pretty complete and straitforward.

I've also taken the opportunity to get more accustomed with Mercurial and I followed the instructions on how to set up hg on sourceforge and got that working pretty well. You can check it out here.

After a rather (too) long discussion on IRC about mercurial with some vocal advocates of distributed systems I thought I might qualify what I said in my previous blog entry.

Since I learned about mercurial I started reading about it and tried it out a little bit. The benefits are obvious but I didn't feel like it represented a huge shift from my previous workflows since I haven't had huge problems thusfar with SVN. Mercurial provides me with some nice new features but there were no deal breakers.

Also, to answer some concerns　that were raised,

1.) When I was learning about mercurial I learned that it's decentralized and that a centralized server is not inherent in it's design, meaning you don't need one. So when I said that it's a decentralized system in my previous post, I didn't mean that I thought that you can't have a centralized server, and that presents a problem. I merely meant that it's not practical if you don't have a centralized server. So the idea of decentralization is practically speaking not radically different than SVN was in this regard. I still, practically speaking, have to email the maintainer or mailing list with patches and hope someone checks them in for me. Sharing them with another developer directly won't happen very often. That particular advantage is not a reason I would use it (though I'll look into the hg email features some more. I think it's somewhat easy for someone to mail diffs of their changes and somewhat easy for you to download the e-mail and automatically merge it into your branch).

2.) I wasn't saying that the issues I mentioned were arguments for not using mercurial. In fact they don't matter much since they are somewhat minor issues, and the benefits such as being able to track revisions locally and managing branching and merging easier do make it worth while. So I wasn't resisting it, I just wasn't jumping up and down for joy about being able to use the new features. Partly because I can't anyway. I don't have a server to install it on. I don't have my own repositiories for my own projects (I use sourceforge for hosting) and even if I had access to the repositories of other projects I have contributed to, they use SVN. And partly because I was marginally happy using SVN.

So in conclusion, if given the choice I would use mercurial. I'm just not going to let the fact that SVN has some shortcomings keep me from using it and contributing to projects that use it.

I just had the pleasure of watching this video of a Google Tech Talk by Bryan O'Sullivan on the Mercurial project. Mercurial is a distributed version control system which seems to have some nice benefits. While I haven't used it yet, or any other distributed version control system for that matter, It seems like it would fit well with open source developers and projects because you can maintain change revisions locally and then submit them to a particular project for review easier without the notion of commiters and non-commiters. But while I recognize the benefits of mercurial I also foresee some problems with picking it up and using it.

One is that in it's purest form it's completely distributed which would mean that you need to know other people's IP addresses in order to connect to the developer's box directly and push/pull changes. That has two sub problems. One is that many people, including myself don't allow remote access to my desktop machine, and even if they did it might be hard as without a static IP you couldn't guarantee it would be the same and you might not even notice when it changes. Subproblem two is that with more than a few developers it would soon be hard to maintain connections to each person's box in order to push changes. So basically, though it's a benefit to not really having a notion of a central repository, you will almost always have something that functions similarly to a central repository, whether it be a lead developers box or a centralized server.

Another is that the notion of a centralized trunk branch is easy to understand and navigate. Of course I don't have experience to speak from but it feels like it would be hard to keep track of making sure that all the revisions you reviewed are actually in the version of the program that you are packaging and distributing. Basically you would still need some notion of a central trunk branch somewhere. Though, it would be nice for a group of developers to easily/automatically create a branch and do concurrent development on some new feature. All they would need to do is take their own local branches and start adding the features and only share with their own group. And later they could come back when they are ready and merge their changes with the main trunk branch group.

In any case Bryan O'Sullivan had some interesting insights into revision control and made a good case for using mercurial. He was surprisingly well spoken though he had some computer/technology difficulty with his slides and didn't seem to like the level of help he was getting from the gentleman trying to get Bryan's slides working. Anyway, I look forward to trying it out on some new projects. Maybe on the new web interface for Anki.