Friday, May 25, 2007

Patch Queues

The idea of Version Control Systems is awesome. A Decentralized Version Control System is an even greater idea for a distributed working environment such as the, and most, project I'm working on now.

Also a great idea is the idea of diff patches. To be able to take an original file and compare it to a modified version and get a representation of the changes is great for programming. Taking this idea a step further you get patch queues.

The idea of a patch queue is rather simple. Before you start working, you initialize a queue that will store a series of patches to be applied to a file or group of files. You then create a patch. Then you proceed as normal and work. At any point you can update the patch to reflect the changes that have been made since the start of the patch. So far so good right? Now comes the awesome part. After having updated a patch to reflect the changes, you can then start a new patch and push it on top of the first patch. This patch will reflect a series of other changes. After having updated this patch you can now do one of the following. You can either push a new patch on the queue or you can pop the new patch off the queue to modify the first patch. When you are satisfied with the changes you've made to the first patch you can then push the second patch back on top and continue working on it! Genius, pure genius!

A good friend of mine, you know who you are buddy, brought this concept to my attention minutes after I was accepted into GSoC saying, "You are going to need this.". I hadn't bothered to make it much available because one of the Pidgin developers told me that the project was too simple and we didn't need that kind of functionality. Well, after a bit of work I found that I didn't agree. It wasn't two days after I had started working on my first set of changes that I was looking for the ability to push multiple patches onto a queue as I worked. It's not that my work was very complicated, in fact the bit of work I was doing was only like 10 lines of new code. It was that midway in my work I wanted to go make a small change to a function somewhere else and I didn't want to confuse my current changeset. By being able to push a new patch, make those changes, and then come back to the first patch, it would have made it simple.

Now if this idea of patches queues doesn't blow you out of the water, how about I tell you that Mercurial has built into their system the ability to tie in both patch queues and a DVCS? Think of it, for as long as VCS's go back, once you commit a change, they are there forever, you can't take them back. Some allow you to disapprove changes, but this can get rather dicey. With the idea of patch queues into a DVCS, patches are treated as changesets. The only difference is that you can move up and down the graph with the use of a patch queue and modify a changeset after it was "committed". Mercurial has called them Mercurial Queues (MQ). I know rather little about project development, but I can see the beauty of this system. I encourage others to use it and lavish in its power.

1 comment:

mithro said...

This is exactly is also how st-git works.

From their homepage,
“StGIT is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of GIT. These operations are performed using GIT commands and the patches are stored as GIT commit objects, allowing easy merging of the StGIT patches into other repositories using standard GIT functionality.”

I would recommend checking it out if your project uses git rather then hg.