Ian Lewis' Blog

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.