Applying patches: the patch program

javelin's picture

Changes and bugfixes to the MUSH code are often distributed as patches in context diff format. Diffs are files which describe how the source code should be changed. The program "patch" (by Larry Wall, distributed by the GNU project) automatically reads these files and makes the changes to your source code. If you don't have the patch program, ask your system administrator to get it! (A version for Win32 systems is available at http://unxutils.sourceforge.net)

Typically, you can get patches to PennMUSH from the pennmush mailing list or FTP site. To apply a patch, place it in your top-level pennmush directory. Then READ THE PATCH FILE.

PennMUSH patches contain instructions at the top of the file. These instructions can be very important, and can differ from patch to patch. Always read the patch file.

That said, the most common instruction is to apply the patch by typing:

    patch -p1 < patchfile

in order to process the patch.

The patch program is very smart. The changes in the context diff are split into hunks. Each hunk represents a section of code that's been changed (and that's far enough away from any other code changes to be handled separately). A hunk includes information about the line numbers in the original file where the change was made, along with a few lines of context -- lines of code that haven't changed but surround the changed lines. Using this context, patch can apply the changes in the right place even if you've modified other sections of the program.

Sometimes, however, you may have made changes that overlap the changes in a patch hunk. In this case, the hunk will fail to patch because the patch program won't find the appropriate context. When this happens, you need to read the failed hunk yourself and apply the changes by hand. Failed hunks are usually named for the file they were intended for, but end in .rej (e.g. "bsd.c.rej").

Here's how to read a failed hunk (this is based on an email message by T. Alexander Popiel):

  • If the diff begins with the line "Prereq: ", then it means that in the file that follows, the string should be present within the first few lines, or the diff should not be applied. Patch checks for prerequisites to help insure that you're patching the right version of the source code. For example, PennMUSH patches always start by patching the Patchlevel file, and use the contents of that file as a prerequisite to be sure you don't apply 1.7.7-patch08 to the 1.7.7p4 version by mistake.
  • For each file in the diff, there are two header lines, which look like this:
    *** filename1	date1
    --- filename2	date2

    This indicates that the diff is the difference between filename1 and filename2, and should usually be applied to filename2.

  • After the header lines, the diff will indicate which line numbers in filename1 (the source) are to be examined, what should be changed or deleted, what the resulting line numbers in filename2 (the destination) are, and what should
    be changed or added:
    • A '-' in the first column of the source part of the patch indicates a line deletion.
    • A '+' in the first column of the destination part of the
      patch indicates a line addition.
    • A set of '!'s in the first column in both the source and the destination indicate a line-group replacement; a group of consecutive lines in the source are replaced with a corresponding group of lines in the destination.

The patch program can also "reverse" a patch, applying it backward to turn the new version back into the old version. To reverse a patch, you feed the patch to the patch program giving it the "-R" switch.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Very good introduction on

Very good introduction on how to patch up PennMUSH.

I would also like to point out that whenever I patch pennmush, I always do a 'dry run' before the official patch so that I can see ahead of time what parts may fail.

To do a dry run it is the same as the patch process above but with the option '--dry-run' so for example (using the example above)

patch -p1 --dry-run < patchfile

Once that is done and you have seen that the patch will run fine, you can do the normal patch, otherwise, if it suggests that parts may fail, then you can easilly see them before hand and fix if necessary or deal with the resulting reject file when you do the actual patch.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.