Thursday, May 31, 2007

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.

... OR

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.

/ \
... OR IRR
\ /

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.

No comments: