Mercurial_ The Definitive Guide - Bryan O'Sullivan [91]
You can change which patches are applied to the tree. If you “pop” a patch, the changes made by that patch will vanish from the directory tree. Quilt remembers which patches you have popped, though, so you can “push” a popped patch again, and the directory tree will be restored to contain the modifications in the patch. Most importantly, you can run the “refresh” command at any time, and the topmost applied patch will be updated. This means that you can, at any time, change both which patches are applied and what modifications those patches make.
Quilt knows nothing about revision control tools, so it works equally well on top of an unpacked tarball or a Subversion working copy.
From Patchwork Quilt to Mercurial Queues
In mid-2005, Chris Mason took the features of quilt and wrote an extension that he called Mercurial Queues, which added quilt-like behavior to Mercurial.
The key difference between quilt and MQ is that quilt knows nothing about revision control systems, while MQ is integrated into Mercurial. Each patch that you push is represented as a Mercurial changeset. Pop a patch, and the changeset goes away.
Because quilt does not care about revision control tools, it is still a tremendously useful piece of software to know about for situations where you cannot use Mercurial and MQ.
The Huge Advantage of MQ
I cannot overstate the value that MQ offers through the unification of patches and revision control.
A major reason that patches have persisted in the free software and open source world—in spite of the availability of increasingly capable revision control tools over the years—is the agility they offer.
Traditional revision control tools make a permanent, irreversible record of everything that you do. While this has great value, it’s also somewhat stifling. If you want to perform a wild-eyed experiment, you have to be careful in how you go about it, or you risk leaving unnecessary—or worse, misleading or destabilizing—traces of your missteps and errors in the permanent revision record.
By contrast, MQ’s marriage of distributed revision control with patches makes it much easier to isolate your work. Your patches live on top of normal revision history, and you can make them disappear or reappear at will. If you don’t like a patch, you can drop it. If a patch isn’t quite as you want it to be, simply fix it—as many times as you need to, until you have refined it into the form you desire.
As an example, the integration of patches with revision control makes understanding patches and debugging their effects—and their interplay with the code they’re based on—enormously easier. Since every applied patch has an associated changeset, you can give hg log a filename to see which changesets and patches affected the file. You can use the hg bisect command to binary-search through all changesets and applied patches to see where a bug got introduced or fixed. You can use the hg annotate command to see which changeset or patch modified a particular line of a source file. And so on.
Understanding Patches
Because MQ doesn’t hide its patch-oriented nature, it is helpful to understand what patches are, and a little about the tools that work with them.
The traditional Unix diff command compares two files, and prints a list of differences between them. The patch command understands these differences as modifications to make to a file. Here is a simple example of these commands in action.
$ echo 'this is my original thought' > oldfile
$ echo 'i have changed my mind' > newfile
$ diff -u oldfile newfile > tiny.patch
$ cat tiny.patch
--- oldfile 2009-05-05 06:44:39.554480179 +0000
+++ newfile 2009-05-05 06:44:39.554480179 +0000
@@ -1 +1 @@
-this is my original thought
+i have changed my mind
$ patch < tiny.patch
patching file oldfile
$ cat oldfile
i have changed my mind
The type of file that