hgbook

annotate en/hgext.tex @ 514:db12ab3b3b25

find changesets by author, revision, files, or words in the commit message
corrected some typos on the title page.

translated a couple of index entries
author Javier Rojas <jerojasro@devnull.li>
date Sun Jan 18 19:45:33 2009 -0500 (2009-01-18)
parents 7df934d3dcb5
children
rev   line source
bos@223 1 \chapter{Adding functionality with extensions}
bos@223 2 \label{chap:hgext}
bos@223 3
bos@224 4 While the core of Mercurial is quite complete from a functionality
bos@224 5 standpoint, it's deliberately shorn of fancy features. This approach
bos@224 6 of preserving simplicity keeps the software easy to deal with for both
bos@224 7 maintainers and users.
bos@224 8
bos@224 9 However, Mercurial doesn't box you in with an inflexible command set:
bos@224 10 you can add features to it as \emph{extensions} (sometimes known as
bos@224 11 \emph{plugins}). We've already discussed a few of these extensions in
bos@224 12 earlier chapters.
bos@224 13 \begin{itemize}
bos@224 14 \item Section~\ref{sec:tour-merge:fetch} covers the \hgext{fetch}
bos@224 15 extension; this combines pulling new changes and merging them with
bos@231 16 local changes into a single command, \hgxcmd{fetch}{fetch}.
bos@224 17 \item In chapter~\ref{chap:hook}, we covered several extensions that
bos@224 18 are useful for hook-related functionality: \hgext{acl} adds access
bos@224 19 control lists; \hgext{bugzilla} adds integration with the Bugzilla
bos@224 20 bug tracking system; and \hgext{notify} sends notification emails on
bos@224 21 new changes.
bos@224 22 \item The Mercurial Queues patch management extension is so invaluable
bos@224 23 that it merits two chapters and an appendix all to itself.
bos@224 24 Chapter~\ref{chap:mq} covers the basics;
bos@224 25 chapter~\ref{chap:mq-collab} discusses advanced topics; and
bos@224 26 appendix~\ref{chap:mqref} goes into detail on each command.
bos@224 27 \end{itemize}
bos@224 28
bos@224 29 In this chapter, we'll cover some of the other extensions that are
bos@224 30 available for Mercurial, and briefly touch on some of the machinery
bos@224 31 you'll need to know about if you want to write an extension of your
bos@224 32 own.
bos@224 33 \begin{itemize}
bos@224 34 \item In section~\ref{sec:hgext:inotify}, we'll discuss the
bos@224 35 possibility of \emph{huge} performance improvements using the
bos@224 36 \hgext{inotify} extension.
bos@224 37 \end{itemize}
bos@224 38
bos@224 39 \section{Improve performance with the \hgext{inotify} extension}
bos@224 40 \label{sec:hgext:inotify}
bos@224 41
bos@224 42 Are you interested in having some of the most common Mercurial
bos@224 43 operations run as much as a hundred times faster? Read on!
bos@224 44
bos@224 45 Mercurial has great performance under normal circumstances. For
bos@224 46 example, when you run the \hgcmd{status} command, Mercurial has to
bos@224 47 scan almost every directory and file in your repository so that it can
bos@224 48 display file status. Many other Mercurial commands need to do the
bos@224 49 same work behind the scenes; for example, the \hgcmd{diff} command
bos@224 50 uses the status machinery to avoid doing an expensive comparison
bos@224 51 operation on files that obviously haven't changed.
bos@224 52
bos@224 53 Because obtaining file status is crucial to good performance, the
bos@224 54 authors of Mercurial have optimised this code to within an inch of its
bos@224 55 life. However, there's no avoiding the fact that when you run
bos@224 56 \hgcmd{status}, Mercurial is going to have to perform at least one
bos@224 57 expensive system call for each managed file to determine whether it's
bos@224 58 changed since the last time Mercurial checked. For a sufficiently
bos@224 59 large repository, this can take a long time.
bos@224 60
bos@224 61 To put a number on the magnitude of this effect, I created a
bos@224 62 repository containing 150,000 managed files. I timed \hgcmd{status}
bos@224 63 as taking ten seconds to run, even when \emph{none} of those files had
bos@224 64 been modified.
bos@224 65
bos@224 66 Many modern operating systems contain a file notification facility.
bos@224 67 If a program signs up to an appropriate service, the operating system
bos@224 68 will notify it every time a file of interest is created, modified, or
bos@224 69 deleted. On Linux systems, the kernel component that does this is
bos@224 70 called \texttt{inotify}.
bos@224 71
bos@224 72 Mercurial's \hgext{inotify} extension talks to the kernel's
bos@224 73 \texttt{inotify} component to optimise \hgcmd{status} commands. The
bos@224 74 extension has two components. A daemon sits in the background and
bos@224 75 receives notifications from the \texttt{inotify} subsystem. It also
bos@224 76 listens for connections from a regular Mercurial command. The
bos@224 77 extension modifies Mercurial's behaviour so that instead of scanning
bos@224 78 the filesystem, it queries the daemon. Since the daemon has perfect
bos@224 79 information about the state of the repository, it can respond with a
bos@224 80 result instantaneously, avoiding the need to scan every directory and
bos@224 81 file in the repository.
bos@224 82
bos@224 83 Recall the ten seconds that I measured plain Mercurial as taking to
bos@224 84 run \hgcmd{status} on a 150,000 file repository. With the
bos@224 85 \hgext{inotify} extension enabled, the time dropped to 0.1~seconds, a
bos@224 86 factor of \emph{one hundred} faster.
bos@224 87
bos@224 88 Before we continue, please pay attention to some caveats.
bos@224 89 \begin{itemize}
bos@224 90 \item The \hgext{inotify} extension is Linux-specific. Because it
bos@224 91 interfaces directly to the Linux kernel's \texttt{inotify}
bos@224 92 subsystem, it does not work on other operating systems.
bos@224 93 \item It should work on any Linux distribution that was released after
bos@224 94 early~2005. Older distributions are likely to have a kernel that
bos@224 95 lacks \texttt{inotify}, or a version of \texttt{glibc} that does not
bos@224 96 have the necessary interfacing support.
bos@224 97 \item Not all filesystems are suitable for use with the
bos@224 98 \hgext{inotify} extension. Network filesystems such as NFS are a
bos@224 99 non-starter, for example, particularly if you're running Mercurial
bos@224 100 on several systems, all mounting the same network filesystem. The
bos@224 101 kernel's \texttt{inotify} system has no way of knowing about changes
bos@224 102 made on another system. Most local filesystems (e.g.~ext3, XFS,
bos@224 103 ReiserFS) should work fine.
bos@224 104 \end{itemize}
bos@224 105
bos@224 106 The \hgext{inotify} extension is not yet shipped with Mercurial as of
bos@224 107 May~2007, so it's a little more involved to set up than other
bos@224 108 extensions. But the performance improvement is worth it!
bos@224 109
bos@224 110 The extension currently comes in two parts: a set of patches to the
bos@224 111 Mercurial source code, and a library of Python bindings to the
bos@224 112 \texttt{inotify} subsystem.
bos@224 113 \begin{note}
bos@224 114 There are \emph{two} Python \texttt{inotify} binding libraries. One
bos@224 115 of them is called \texttt{pyinotify}, and is packaged by some Linux
bos@224 116 distributions as \texttt{python-inotify}. This is \emph{not} the
bos@224 117 one you'll need, as it is too buggy and inefficient to be practical.
bos@224 118 \end{note}
bos@224 119 To get going, it's best to already have a functioning copy of
bos@224 120 Mercurial installed.
bos@224 121 \begin{note}
bos@224 122 If you follow the instructions below, you'll be \emph{replacing} and
bos@224 123 overwriting any existing installation of Mercurial that you might
bos@224 124 already have, using the latest ``bleeding edge'' Mercurial code.
bos@224 125 Don't say you weren't warned!
bos@224 126 \end{note}
bos@224 127 \begin{enumerate}
bos@224 128 \item Clone the Python \texttt{inotify} binding repository. Build and
bos@224 129 install it.
bos@224 130 \begin{codesample4}
bos@224 131 hg clone http://hg.kublai.com/python/inotify
bos@224 132 cd inotify
bos@224 133 python setup.py build --force
bos@224 134 sudo python setup.py install --skip-build
bos@224 135 \end{codesample4}
bos@224 136 \item Clone the \dirname{crew} Mercurial repository. Clone the
bos@224 137 \hgext{inotify} patch repository so that Mercurial Queues will be
bos@224 138 able to apply patches to your cope of the \dirname{crew} repository.
bos@224 139 \begin{codesample4}
bos@224 140 hg clone http://hg.intevation.org/mercurial/crew
bos@224 141 hg clone crew inotify
bos@224 142 hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
bos@224 143 \end{codesample4}
bos@224 144 \item Make sure that you have the Mercurial Queues extension,
bos@224 145 \hgext{mq}, enabled. If you've never used MQ, read
bos@224 146 section~\ref{sec:mq:start} to get started quickly.
bos@224 147 \item Go into the \dirname{inotify} repo, and apply all of the
bos@231 148 \hgext{inotify} patches using the \hgxopt{mq}{qpush}{-a} option to
bos@231 149 the \hgxcmd{mq}{qpush} command.
bos@224 150 \begin{codesample4}
bos@224 151 cd inotify
bos@224 152 hg qpush -a
bos@224 153 \end{codesample4}
bos@231 154 If you get an error message from \hgxcmd{mq}{qpush}, you should not
bos@224 155 continue. Instead, ask for help.
bos@224 156 \item Build and install the patched version of Mercurial.
bos@224 157 \begin{codesample4}
bos@224 158 python setup.py build --force
bos@224 159 sudo python setup.py install --skip-build
bos@224 160 \end{codesample4}
bos@224 161 \end{enumerate}
bos@224 162 Once you've build a suitably patched version of Mercurial, all you
bos@224 163 need to do to enable the \hgext{inotify} extension is add an entry to
bos@224 164 your \hgrc.
bos@224 165 \begin{codesample2}
bos@224 166 [extensions]
bos@224 167 inotify =
bos@224 168 \end{codesample2}
bos@224 169 When the \hgext{inotify} extension is enabled, Mercurial will
bos@224 170 automatically and transparently start the status daemon the first time
bos@224 171 you run a command that needs status in a repository. It runs one
bos@224 172 status daemon per repository.
bos@224 173
bos@224 174 The status daemon is started silently, and runs in the background. If
bos@224 175 you look at a list of running processes after you've enabled the
bos@224 176 \hgext{inotify} extension and run a few commands in different
bos@224 177 repositories, you'll thus see a few \texttt{hg} processes sitting
bos@224 178 around, waiting for updates from the kernel and queries from
bos@224 179 Mercurial.
bos@224 180
bos@224 181 The first time you run a Mercurial command in a repository when you
bos@224 182 have the \hgext{inotify} extension enabled, it will run with about the
bos@224 183 same performance as a normal Mercurial command. This is because the
bos@224 184 status daemon needs to perform a normal status scan so that it has a
bos@224 185 baseline against which to apply later updates from the kernel.
bos@224 186 However, \emph{every} subsequent command that does any kind of status
bos@224 187 check should be noticeably faster on repositories of even fairly
bos@224 188 modest size. Better yet, the bigger your repository is, the greater a
bos@224 189 performance advantage you'll see. The \hgext{inotify} daemon makes
bos@224 190 status operations almost instantaneous on repositories of all sizes!
bos@224 191
bos@224 192 If you like, you can manually start a status daemon using the
bos@231 193 \hgxcmd{inotify}{inserve} command. This gives you slightly finer
bos@231 194 control over how the daemon ought to run. This command will of course
bos@231 195 only be available when the \hgext{inotify} extension is enabled.
bos@224 196
bos@224 197 When you're using the \hgext{inotify} extension, you should notice
bos@224 198 \emph{no difference at all} in Mercurial's behaviour, with the sole
bos@224 199 exception of status-related commands running a whole lot faster than
bos@224 200 they used to. You should specifically expect that commands will not
bos@224 201 print different output; neither should they give different results.
bos@224 202 If either of these situations occurs, please report a bug.
bos@223 203
bos@226 204 \section{Flexible diff support with the \hgext{extdiff} extension}
bos@226 205 \label{sec:hgext:extdiff}
bos@226 206
bos@226 207 Mercurial's built-in \hgcmd{diff} command outputs plaintext unified
bos@226 208 diffs.
bos@226 209 \interaction{extdiff.diff}
bos@226 210 If you would like to use an external tool to display modifications,
bos@226 211 you'll want to use the \hgext{extdiff} extension. This will let you
bos@226 212 use, for example, a graphical diff tool.
bos@226 213
bos@226 214 The \hgext{extdiff} extension is bundled with Mercurial, so it's easy
bos@226 215 to set up. In the \rcsection{extensions} section of your \hgrc,
bos@226 216 simply add a one-line entry to enable the extension.
bos@226 217 \begin{codesample2}
bos@226 218 [extensions]
bos@226 219 extdiff =
bos@226 220 \end{codesample2}
bos@231 221 This introduces a command named \hgxcmd{extdiff}{extdiff}, which by
bos@231 222 default uses your system's \command{diff} command to generate a
bos@231 223 unified diff in the same form as the built-in \hgcmd{diff} command.
bos@226 224 \interaction{extdiff.extdiff}
bos@226 225 The result won't be exactly the same as with the built-in \hgcmd{diff}
bos@226 226 variations, because the output of \command{diff} varies from one
bos@226 227 system to another, even when passed the same options.
bos@226 228
bos@226 229 As the ``\texttt{making snapshot}'' lines of output above imply, the
bos@231 230 \hgxcmd{extdiff}{extdiff} command works by creating two snapshots of
bos@231 231 your source tree. The first snapshot is of the source revision; the
bos@231 232 second, of the target revision or working directory. The
bos@231 233 \hgxcmd{extdiff}{extdiff} command generates these snapshots in a
bos@231 234 temporary directory, passes the name of each directory to an external
bos@231 235 diff viewer, then deletes the temporary directory. For efficiency, it
bos@231 236 only snapshots the directories and files that have changed between the
bos@231 237 two revisions.
bos@226 238
bos@226 239 Snapshot directory names have the same base name as your repository.
bos@226 240 If your repository path is \dirname{/quux/bar/foo}, then \dirname{foo}
bos@226 241 will be the name of each snapshot directory. Each snapshot directory
bos@226 242 name has its changeset ID appended, if appropriate. If a snapshot is
bos@226 243 of revision \texttt{a631aca1083f}, the directory will be named
bos@226 244 \dirname{foo.a631aca1083f}. A snapshot of the working directory won't
bos@226 245 have a changeset ID appended, so it would just be \dirname{foo} in
bos@226 246 this example. To see what this looks like in practice, look again at
bos@231 247 the \hgxcmd{extdiff}{extdiff} example above. Notice that the diff has
bos@231 248 the snapshot directory names embedded in its header.
bos@231 249
bos@231 250 The \hgxcmd{extdiff}{extdiff} command accepts two important options.
bos@231 251 The \hgxopt{extdiff}{extdiff}{-p} option lets you choose a program to
bos@231 252 view differences with, instead of \command{diff}. With the
bos@231 253 \hgxopt{extdiff}{extdiff}{-o} option, you can change the options that
bos@231 254 \hgxcmd{extdiff}{extdiff} passes to the program (by default, these
bos@231 255 options are ``\texttt{-Npru}'', which only make sense if you're
bos@231 256 running \command{diff}). In other respects, the
bos@231 257 \hgxcmd{extdiff}{extdiff} command acts similarly to the built-in
bos@231 258 \hgcmd{diff} command: you use the same option names, syntax, and
bos@231 259 arguments to specify the revisions you want, the files you want, and
bos@231 260 so on.
bos@226 261
bos@226 262 As an example, here's how to run the normal system \command{diff}
bos@226 263 command, getting it to generate context diffs (using the
bos@226 264 \cmdopt{diff}{-c} option) instead of unified diffs, and five lines of
bos@226 265 context instead of the default three (passing \texttt{5} as the
bos@226 266 argument to the \cmdopt{diff}{-C} option).
bos@226 267 \interaction{extdiff.extdiff-ctx}
bos@226 268
bos@226 269 Launching a visual diff tool is just as easy. Here's how to launch
bos@226 270 the \command{kdiff3} viewer.
bos@226 271 \begin{codesample2}
bos@226 272 hg extdiff -p kdiff3 -o ''
bos@226 273 \end{codesample2}
bos@226 274
bos@226 275 If your diff viewing command can't deal with directories, you can
bos@226 276 easily work around this with a little scripting. For an example of
bos@226 277 such scripting in action with the \hgext{mq} extension and the
bos@226 278 \command{interdiff} command, see
bos@226 279 section~\ref{mq-collab:tips:interdiff}.
bos@226 280
bos@226 281 \subsection{Defining command aliases}
bos@226 282
bos@226 283 It can be cumbersome to remember the options to both the
bos@231 284 \hgxcmd{extdiff}{extdiff} command and the diff viewer you want to use,
bos@231 285 so the \hgext{extdiff} extension lets you define \emph{new} commands
bos@231 286 that will invoke your diff viewer with exactly the right options.
bos@226 287
bos@226 288 All you need to do is edit your \hgrc, and add a section named
bos@226 289 \rcsection{extdiff}. Inside this section, you can define multiple
bos@226 290 commands. Here's how to add a \texttt{kdiff3} command. Once you've
bos@226 291 defined this, you can type ``\texttt{hg kdiff3}'' and the
bos@226 292 \hgext{extdiff} extension will run \command{kdiff3} for you.
bos@226 293 \begin{codesample2}
bos@226 294 [extdiff]
bos@226 295 cmd.kdiff3 =
bos@226 296 \end{codesample2}
bos@226 297 If you leave the right hand side of the definition empty, as above,
bos@226 298 the \hgext{extdiff} extension uses the name of the command you defined
bos@226 299 as the name of the external program to run. But these names don't
bos@226 300 have to be the same. Here, we define a command named ``\texttt{hg
bos@226 301 wibble}'', which runs \command{kdiff3}.
bos@226 302 \begin{codesample2}
bos@226 303 [extdiff]
bos@226 304 cmd.wibble = kdiff3
bos@226 305 \end{codesample2}
bos@226 306
bos@226 307 You can also specify the default options that you want to invoke your
bos@226 308 diff viewing program with. The prefix to use is ``\texttt{opts.}'',
bos@226 309 followed by the name of the command to which the options apply. This
bos@226 310 example defines a ``\texttt{hg vimdiff}'' command that runs the
bos@226 311 \command{vim} editor's \texttt{DirDiff} extension.
bos@226 312 \begin{codesample2}
bos@226 313 [extdiff]
bos@226 314 cmd.vimdiff = vim
bos@226 315 opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
bos@226 316 \end{codesample2}
bos@226 317
bos@232 318 \section{Cherrypicking changes with the \hgext{transplant} extension}
bos@232 319 \label{sec:hgext:transplant}
bos@232 320
bos@232 321 Need to have a long chat with Brendan about this.
bos@232 322
bos@232 323 \section{Send changes via email with the \hgext{patchbomb} extension}
bos@232 324 \label{sec:hgext:patchbomb}
bos@232 325
bos@232 326 Many projects have a culture of ``change review'', in which people
bos@232 327 send their modifications to a mailing list for others to read and
bos@232 328 comment on before they commit the final version to a shared
bos@232 329 repository. Some projects have people who act as gatekeepers; they
bos@232 330 apply changes from other people to a repository to which those others
bos@232 331 don't have access.
bos@232 332
bos@232 333 Mercurial makes it easy to send changes over email for review or
bos@232 334 application, via its \hgext{patchbomb} extension. The extension is so
bos@232 335 namd because changes are formatted as patches, and it's usual to send
bos@232 336 one changeset per email message. Sending a long series of changes by
bos@232 337 email is thus much like ``bombing'' the recipient's inbox, hence
bos@232 338 ``patchbomb''.
bos@232 339
bos@232 340 As usual, the basic configuration of the \hgext{patchbomb} extension
bos@232 341 takes just one or two lines in your \hgrc.
bos@232 342 \begin{codesample2}
bos@232 343 [extensions]
bos@232 344 patchbomb =
bos@232 345 \end{codesample2}
bos@232 346 Once you've enabled the extension, you will have a new command
bos@241 347 available, named \hgxcmd{patchbomb}{email}.
bos@232 348
bos@243 349 The safest and best way to invoke the \hgxcmd{patchbomb}{email}
bos@243 350 command is to \emph{always} run it first with the
bos@243 351 \hgxopt{patchbomb}{email}{-n} option. This will show you what the
bos@243 352 command \emph{would} send, without actually sending anything. Once
bos@243 353 you've had a quick glance over the changes and verified that you are
bos@243 354 sending the right ones, you can rerun the same command, with the
bos@243 355 \hgxopt{patchbomb}{email}{-n} option removed.
bos@243 356
bos@243 357 The \hgxcmd{patchbomb}{email} command accepts the same kind of
bos@243 358 revision syntax as every other Mercurial command. For example, this
bos@243 359 command will send every revision between 7 and \texttt{tip},
bos@243 360 inclusive.
bos@243 361 \begin{codesample2}
bos@243 362 hg email -n 7:tip
bos@243 363 \end{codesample2}
bos@243 364 You can also specify a \emph{repository} to compare with. If you
bos@243 365 provide a repository but no revisions, the \hgxcmd{patchbomb}{email}
bos@243 366 command will send all revisions in the local repository that are not
bos@243 367 present in the remote repository. If you additionally specify
bos@243 368 revisions or a branch name (the latter using the
bos@243 369 \hgxopt{patchbomb}{email}{-b} option), this will constrain the
bos@243 370 revisions sent.
bos@243 371
bos@243 372 It's perfectly safe to run the \hgxcmd{patchbomb}{email} command
bos@243 373 without the names of the people you want to send to: if you do this,
bos@243 374 it will just prompt you for those values interactively. (If you're
bos@243 375 using a Linux or Unix-like system, you should have enhanced
bos@243 376 \texttt{readline}-style editing capabilities when entering those
bos@243 377 headers, too, which is useful.)
bos@243 378
bos@243 379 When you are sending just one revision, the \hgxcmd{patchbomb}{email}
bos@243 380 command will by default use the first line of the changeset
bos@243 381 description as the subject of the single email message it sends.
bos@243 382
bos@243 383 If you send multiple revisions, the \hgxcmd{patchbomb}{email} command
bos@243 384 will usually send one message per changeset. It will preface the
bos@243 385 series with an introductory message, in which you should describe the
bos@243 386 purpose of the series of changes you're sending.
bos@243 387
bos@243 388 \subsection{Changing the behaviour of patchbombs}
bos@243 389
bos@243 390 Not every project has exactly the same conventions for sending changes
bos@243 391 in email; the \hgext{patchbomb} extension tries to accommodate a
bos@243 392 number of variations through command line options.
bos@243 393 \begin{itemize}
bos@243 394 \item You can write a subject for the introductory message on the
bos@243 395 command line using the \hgxopt{patchbomb}{email}{-s} option. This
bos@243 396 takes one argument, the text of the subject to use.
bos@243 397 \item To change the email address from which the messages originate,
bos@243 398 use the \hgxopt{patchbomb}{email}{-f} option. This takes one
bos@243 399 argument, the email address to use.
bos@243 400 \item The default behaviour is to send unified diffs (see
bos@243 401 section~\ref{sec:mq:patch} for a description of the format), one per
bos@243 402 message. You can send a binary bundle instead with the
bos@243 403 \hgxopt{patchbomb}{email}{-b} option.
bos@243 404 \item Unified diffs are normally prefaced with a metadata header. You
bos@243 405 can omit this, and send unadorned diffs, with the
bos@243 406 \hgxopt{patchbomb}{email}{--plain} option.
bos@243 407 \item Diffs are normally sent ``inline'', in the same body part as the
bos@243 408 description of a patch. This makes it easiest for the largest
bos@243 409 number of readers to quote and respond to parts of a diff, as some
bos@243 410 mail clients will only quote the first MIME body part in a message.
bos@243 411 If you'd prefer to send the description and the diff in separate
bos@243 412 body parts, use the \hgxopt{patchbomb}{email}{-a} option.
bos@243 413 \item Instead of sending mail messages, you can write them to an
bos@243 414 \texttt{mbox}-format mail folder using the
bos@243 415 \hgxopt{patchbomb}{email}{-m} option. That option takes one
bos@243 416 argument, the name of the file to write to.
bos@243 417 \item If you would like to add a \command{diffstat}-format summary to
bos@243 418 each patch, and one to the introductory message, use the
bos@243 419 \hgxopt{patchbomb}{email}{-d} option. The \command{diffstat}
bos@243 420 command displays a table containing the name of each file patched,
bos@243 421 the number of lines affected, and a histogram showing how much each
bos@243 422 file is modified. This gives readers a qualitative glance at how
bos@243 423 complex a patch is.
bos@243 424 \end{itemize}
bos@231 425
bos@223 426 %%% Local Variables:
bos@223 427 %%% mode: latex
bos@223 428 %%% TeX-master: "00book"
bos@223 429 %%% End: