Micro Merging

At first I thought to keep my code under both Mercurial, for MQ, and Monotone(MTN), because Pidgin is kept under MTN. But after a bit of work, I've found that it's really annoying. So, as much as I like MQ and think it's a fantastic idea, maintaining code under two DVCS's is too much work for what I want to get out of it. I won't be able to use patch queues until I either get Pidgin to convert to a DVCS that uses patch queues, or when MTN gets them incorporated.

So I am having to find alternate means of doing some of the things I could do with patch queues. So yesterday when I was working on incorporating the ability for Finch to reassign keys, I found that it required additional functionality before this could work. So I had a problem. I couldn't just make those changes then, because they would be incorporated into the same patch of adding reassignment capability, because that would create a messy/non-discrete patch. I also couldn't revert my code back to the previous revision, because that would lose all the changes I had already made. So I was caught. After a bit of thinking it became clear that the solution was simple, due to the power provided by the decentralized nature of MTN. The answer was a micro branch.

I won't bother going into too much detail because MTN micro branching is described well on the wiki. So I had my original revision (OR) that existed before I started any of my work, and I had a new revision that I was working on, we'll call it the reassign revision (RR). But I found that I had to write some code to temporarily ignore keystrokes at the window manager level and had to write code to do that before my RR could work. So I had to write an ignore keys revision (IR). So as it stood my DAG looked like this.

 ... OR --> RR

But for my RR to work properly I had to put in a revision between OR and RR. That's not possible due to the nature of VCS's. So I decided to apply the changes to start IR with OR as its parent. Thus my graph would look like this now.

          ,--RR
      /
... OR
      \
       `--IR

Now IR doesn't happen after RR, which was the primary goal of this exercise. So all I have to do is make sure both IR and RR work well on their own and I can merge the branches when I'm done creating a new revision of both the changes called ignore keys and reassign revision (IRR), creating a DAG that looks like this.

          ,--RR--,
      /        \
... OR            IRR
      \        /
       `--IR--'

This same idea can be used quite nicely for bug fixes. The process is called daggy fixing. I find this method to be very nice and provides for a cleaner and more readable graph.