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.
No comments:
Post a Comment