Mercurial_ The Definitive Guide - Bryan O'Sullivan [102]
150 Hunk #4 static void ipw_pci_remove(struct pci_de
164 File #7 a/drivers/scsi/libata-scsi.c
166 Hunk #1 int ata_cmd_ioctl(struct scsi_device *sc
178 File #8 a/drivers/video/au1100fb.c
180 Hunk #1 void __exit au1100fb_cleanup(void)
This command prints three different kinds of number:
(in the first column) a file number to identify each file modified in the patch
(on the next line, indented) the line number within a modified file where a hunk starts
(on the same line) a hunk number to identify that hunk
You’ll have to use some visual inspection, and reading of the patch, to identify the file and hunk numbers you’ll want, but you can then pass them to filterdiff’s --files and --hunks options, to select exactly the file and hunk you want to extract.
Once you have this hunk, you can concatenate it onto the end of your destination patch and continue with the remainder of Combining Entire Patches.
Differences Between Quilt and MQ
If you are already familiar with quilt, MQ provides a similar command set. There are a few differences in the way that it works.
You will already have noticed that most quilt commands have MQ counterparts that simply begin with a q. The exceptions are quilt’s add and remove commands, the counterparts for which are the normal Mercurial hg add and hg remove commands. There is no MQ equivalent to quilt’s edit command.
Chapter 13. Advanced Uses of Mercurial Queues
While it’s easy to pick up straightforward uses of Mercurial Queues, the use of a little discipline and some of MQ’s less frequently used capabilities makes it possible to work in complicated development environments.
In this chapter, I will use as an example a technique I have used to manage the development of an Infiniband device driver for the Linux kernel. The driver in question is large (at least as drivers go), with 25,000 lines of code spread across 35 source files. It is maintained by a small team of developers.
While much of the material in this chapter is specific to Linux, the same principles apply to any code base for which you’re not the primary owner, and upon which you need to do a lot of development.
The Problem of Many Targets
The Linux kernel changes rapidly and has never been internally stable; developers frequently make drastic changes between releases. This means that a version of the driver that works well with a particular released version of the kernel will typically not even compile correctly against any other version.
To maintain a driver, we have to keep a number of distinct versions of Linux in mind:
One target is the main Linux kernel development tree. Maintenance of the code is in this case partly shared by other developers in the kernel community, who make “drive-by” modifications to the driver as they develop and refine kernel subsystems.
We also maintain a number of “backports” to older versions of the Linux kernel, to support the needs of customers who are running older Linux distributions that do not incorporate our drivers. (To backport a piece of code is to modify it to work in an older version of its target environment than the version it was developed for.)
Finally, we make software releases on a schedule that is necessarily not aligned with those used by Linux distributors and kernel developers, so that we can deliver new features to customers without forcing them to upgrade their entire kernels or distributions.
Tempting Approaches That Don’t Work Well
There are two “standard” ways to maintain a piece of software that has to target many different environments.
The first is to maintain a number of branches, each intended for a single target. The trouble with this approach is that you must maintain iron discipline in the flow of changes between repositories. A new feature or bug fix must start life in a “pristine” repository, then percolate out to every backport repository. Backport changes are more limited in the branches they should propagate to; a backport change that is applied to a branch where it doesn’t belong will probably stop