hgbook

diff fr/ch14-hgext.xml @ 964:6b680d569bb4

deleting a bunch of files not longer necessary to build the documentation.
Adding missing newly files needed to build the documentation
author Romain PELISSE <belaran@gmail.com>
date Sun Aug 16 04:58:01 2009 +0200 (2009-08-16)
parents
children 6f8c48362758
line diff
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/fr/ch14-hgext.xml	Sun Aug 16 04:58:01 2009 +0200
     1.3 @@ -0,0 +1,539 @@
     1.4 +<!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     1.5 +
     1.6 +<chapter>
     1.7 +<title>Adding functionality with extensions</title>
     1.8 +<para>\label{chap:hgext}</para>
     1.9 +
    1.10 +<para>While the core of Mercurial is quite complete from a functionality
    1.11 +standpoint, it's deliberately shorn of fancy features.  This approach
    1.12 +of preserving simplicity keeps the software easy to deal with for both
    1.13 +maintainers and users.</para>
    1.14 +
    1.15 +<para>However, Mercurial doesn't box you in with an inflexible command set:
    1.16 +you can add features to it as <emphasis>extensions</emphasis> (sometimes known as
    1.17 +<emphasis>plugins</emphasis>).  We've already discussed a few of these extensions in
    1.18 +earlier chapters.</para>
    1.19 +<itemizedlist>
    1.20 +<listitem><para>Section <xref linkend="sec:tour-merge:fetch"/> covers the <literal role="hg-ext">fetch</literal>
    1.21 +  extension; this combines pulling new changes and merging them with
    1.22 +  local changes into a single command, <command role="hg-ext-fetch">fetch</command>.</para>
    1.23 +</listitem>
    1.24 +<listitem><para>In chapter <xref linkend="chap:hook"/>, we covered several extensions that
    1.25 +  are useful for hook-related functionality: <literal role="hg-ext">acl</literal> adds access
    1.26 +  control lists; <literal role="hg-ext">bugzilla</literal> adds integration with the Bugzilla
    1.27 +  bug tracking system; and <literal role="hg-ext">notify</literal> sends notification emails on
    1.28 +  new changes.</para>
    1.29 +</listitem>
    1.30 +<listitem><para>The Mercurial Queues patch management extension is so invaluable
    1.31 +  that it merits two chapters and an appendix all to itself.
    1.32 +  Chapter <xref linkend="chap:mq"/> covers the basics;
    1.33 +  chapter <xref linkend="chap:mq-collab"/> discusses advanced topics; and
    1.34 +  appendix <xref linkend="chap:mqref"/> goes into detail on each command.</para>
    1.35 +</listitem></itemizedlist>
    1.36 +
    1.37 +<para>In this chapter, we'll cover some of the other extensions that are
    1.38 +available for Mercurial, and briefly touch on some of the machinery
    1.39 +you'll need to know about if you want to write an extension of your
    1.40 +own.</para>
    1.41 +<itemizedlist>
    1.42 +<listitem><para>In section <xref linkend="sec:hgext:inotify"/>, we'll discuss the
    1.43 +  possibility of <emphasis>huge</emphasis> performance improvements using the
    1.44 +  <literal role="hg-ext">inotify</literal> extension.</para>
    1.45 +</listitem></itemizedlist>
    1.46 +
    1.47 +<sect1>
    1.48 +<title>Improve performance with the <literal role="hg-ext">inotify</literal> extension</title>
    1.49 +<para>\label{sec:hgext:inotify}
    1.50 +</para>
    1.51 +
    1.52 +<para>Are you interested in having some of the most common Mercurial
    1.53 +operations run as much as a hundred times faster?  Read on!
    1.54 +</para>
    1.55 +
    1.56 +<para>Mercurial has great performance under normal circumstances.  For
    1.57 +example, when you run the <command role="hg-cmd">hg status</command> command, Mercurial has to
    1.58 +scan almost every directory and file in your repository so that it can
    1.59 +display file status.  Many other Mercurial commands need to do the
    1.60 +same work behind the scenes; for example, the <command role="hg-cmd">hg diff</command> command
    1.61 +uses the status machinery to avoid doing an expensive comparison
    1.62 +operation on files that obviously haven't changed.
    1.63 +</para>
    1.64 +
    1.65 +<para>Because obtaining file status is crucial to good performance, the
    1.66 +authors of Mercurial have optimised this code to within an inch of its
    1.67 +life.  However, there's no avoiding the fact that when you run
    1.68 +<command role="hg-cmd">hg status</command>, Mercurial is going to have to perform at least one
    1.69 +expensive system call for each managed file to determine whether it's
    1.70 +changed since the last time Mercurial checked.  For a sufficiently
    1.71 +large repository, this can take a long time.
    1.72 +</para>
    1.73 +
    1.74 +<para>To put a number on the magnitude of this effect, I created a
    1.75 +repository containing 150,000 managed files.  I timed <command role="hg-cmd">hg status</command>
    1.76 +as taking ten seconds to run, even when <emphasis>none</emphasis> of those files had
    1.77 +been modified.
    1.78 +</para>
    1.79 +
    1.80 +<para>Many modern operating systems contain a file notification facility.
    1.81 +If a program signs up to an appropriate service, the operating system
    1.82 +will notify it every time a file of interest is created, modified, or
    1.83 +deleted.  On Linux systems, the kernel component that does this is
    1.84 +called <literal>inotify</literal>.
    1.85 +</para>
    1.86 +
    1.87 +<para>Mercurial's <literal role="hg-ext">inotify</literal> extension talks to the kernel's
    1.88 +<literal>inotify</literal> component to optimise <command role="hg-cmd">hg status</command> commands.  The
    1.89 +extension has two components.  A daemon sits in the background and
    1.90 +receives notifications from the <literal>inotify</literal> subsystem.  It also
    1.91 +listens for connections from a regular Mercurial command.  The
    1.92 +extension modifies Mercurial's behaviour so that instead of scanning
    1.93 +the filesystem, it queries the daemon.  Since the daemon has perfect
    1.94 +information about the state of the repository, it can respond with a
    1.95 +result instantaneously, avoiding the need to scan every directory and
    1.96 +file in the repository.
    1.97 +</para>
    1.98 +
    1.99 +<para>Recall the ten seconds that I measured plain Mercurial as taking to
   1.100 +run <command role="hg-cmd">hg status</command> on a 150,000 file repository.  With the
   1.101 +<literal role="hg-ext">inotify</literal> extension enabled, the time dropped to 0.1 seconds, a
   1.102 +factor of <emphasis>one hundred</emphasis> faster.
   1.103 +</para>
   1.104 +
   1.105 +<para>Before we continue, please pay attention to some caveats.
   1.106 +</para>
   1.107 +<itemizedlist>
   1.108 +<listitem><para>The <literal role="hg-ext">inotify</literal> extension is Linux-specific.  Because it
   1.109 +  interfaces directly to the Linux kernel's <literal>inotify</literal>
   1.110 +  subsystem, it does not work on other operating systems.
   1.111 +</para>
   1.112 +</listitem>
   1.113 +<listitem><para>It should work on any Linux distribution that was released after
   1.114 +  early 2005.  Older distributions are likely to have a kernel that
   1.115 +  lacks <literal>inotify</literal>, or a version of <literal>glibc</literal> that does not
   1.116 +  have the necessary interfacing support.
   1.117 +</para>
   1.118 +</listitem>
   1.119 +<listitem><para>Not all filesystems are suitable for use with the
   1.120 +  <literal role="hg-ext">inotify</literal> extension.  Network filesystems such as NFS are a
   1.121 +  non-starter, for example, particularly if you're running Mercurial
   1.122 +  on several systems, all mounting the same network filesystem.  The
   1.123 +  kernel's <literal>inotify</literal> system has no way of knowing about changes
   1.124 +  made on another system.  Most local filesystems (e.g. ext3, XFS,
   1.125 +  ReiserFS) should work fine.
   1.126 +</para>
   1.127 +</listitem></itemizedlist>
   1.128 +
   1.129 +<para>The <literal role="hg-ext">inotify</literal> extension is not yet shipped with Mercurial as of
   1.130 +May 2007, so it's a little more involved to set up than other
   1.131 +extensions.  But the performance improvement is worth it!
   1.132 +</para>
   1.133 +
   1.134 +<para>The extension currently comes in two parts: a set of patches to the
   1.135 +Mercurial source code, and a library of Python bindings to the
   1.136 +<literal>inotify</literal> subsystem.
   1.137 +</para>
   1.138 +<note>
   1.139 +<para>  There are <emphasis>two</emphasis> Python <literal>inotify</literal> binding libraries.  One
   1.140 +  of them is called <literal>pyinotify</literal>, and is packaged by some Linux
   1.141 +  distributions as <literal>python-inotify</literal>.  This is <emphasis>not</emphasis> the
   1.142 +  one you'll need, as it is too buggy and inefficient to be practical.
   1.143 +</para>
   1.144 +</note>
   1.145 +<para>To get going, it's best to already have a functioning copy of
   1.146 +Mercurial installed.
   1.147 +</para>
   1.148 +<note>
   1.149 +<para>  If you follow the instructions below, you'll be <emphasis>replacing</emphasis> and
   1.150 +  overwriting any existing installation of Mercurial that you might
   1.151 +  already have, using the latest <quote>bleeding edge</quote> Mercurial code.
   1.152 +  Don't say you weren't warned!
   1.153 +</para>
   1.154 +</note>
   1.155 +<orderedlist>
   1.156 +<listitem><para>Clone the Python <literal>inotify</literal> binding repository.  Build and
   1.157 +  install it.
   1.158 +</para>
   1.159 +</listitem><programlisting>
   1.160 +<listitem><para>    hg clone http://hg.kublai.com/python/inotify
   1.161 +    cd inotify
   1.162 +    python setup.py build --force
   1.163 +    sudo python setup.py install --skip-build
   1.164 +</para>
   1.165 +</listitem></programlisting>
   1.166 +</para>
   1.167 +</listitem>
   1.168 +<listitem><para>Clone the <filename class="directory">crew</filename> Mercurial repository.  Clone the
   1.169 +  <literal role="hg-ext">inotify</literal> patch repository so that Mercurial Queues will be
   1.170 +  able to apply patches to your cope of the <filename class="directory">crew</filename> repository.
   1.171 +</para>
   1.172 +</listitem><programlisting>
   1.173 +<listitem><para>    hg clone http://hg.intevation.org/mercurial/crew
   1.174 +    hg clone crew inotify
   1.175 +    hg clone http://hg.kublai.com/mercurial/patches/inotify inotify/.hg/patches
   1.176 +</para>
   1.177 +</listitem></programlisting>
   1.178 +</para>
   1.179 +</listitem>
   1.180 +<listitem><para>Make sure that you have the Mercurial Queues extension,
   1.181 +  <literal role="hg-ext">mq</literal>, enabled.  If you've never used MQ, read
   1.182 +  section <xref linkend="sec:mq:start"/> to get started quickly.
   1.183 +</para>
   1.184 +</listitem>
   1.185 +<listitem><para>Go into the <filename class="directory">inotify</filename> repo, and apply all of the
   1.186 +  <literal role="hg-ext">inotify</literal> patches using the <option role="hg-ext-mq-cmd-qpush-opt">-a</option> option to
   1.187 +  the <command role="hg-ext-mq">qpush</command> command.
   1.188 +</para>
   1.189 +</listitem><programlisting>
   1.190 +<listitem><para>    cd inotify
   1.191 +    hg qpush -a
   1.192 +</para>
   1.193 +</listitem></programlisting>
   1.194 +<listitem><para>  If you get an error message from <command role="hg-ext-mq">qpush</command>, you should not
   1.195 +  continue.  Instead, ask for help.
   1.196 +</para>
   1.197 +</listitem>
   1.198 +<listitem><para>Build and install the patched version of Mercurial.
   1.199 +</para>
   1.200 +</listitem><programlisting>
   1.201 +<listitem><para>    python setup.py build --force
   1.202 +    sudo python setup.py install --skip-build
   1.203 +</para>
   1.204 +</listitem></programlisting>
   1.205 +</orderedlist>
   1.206 +<para>Once you've build a suitably patched version of Mercurial, all you
   1.207 +need to do to enable the <literal role="hg-ext">inotify</literal> extension is add an entry to
   1.208 +your <filename role="special"> /.hgrc</filename>.
   1.209 +</para>
   1.210 +<programlisting>
   1.211 +<para>  [extensions]
   1.212 +  inotify =
   1.213 +</para>
   1.214 +</programlisting>
   1.215 +<para>When the <literal role="hg-ext">inotify</literal> extension is enabled, Mercurial will
   1.216 +automatically and transparently start the status daemon the first time
   1.217 +you run a command that needs status in a repository.  It runs one
   1.218 +status daemon per repository.
   1.219 +</para>
   1.220 +
   1.221 +<para>The status daemon is started silently, and runs in the background.  If
   1.222 +you look at a list of running processes after you've enabled the
   1.223 +<literal role="hg-ext">inotify</literal> extension and run a few commands in different
   1.224 +repositories, you'll thus see a few <literal>hg</literal> processes sitting
   1.225 +around, waiting for updates from the kernel and queries from
   1.226 +Mercurial.
   1.227 +</para>
   1.228 +
   1.229 +<para>The first time you run a Mercurial command in a repository when you
   1.230 +have the <literal role="hg-ext">inotify</literal> extension enabled, it will run with about the
   1.231 +same performance as a normal Mercurial command.  This is because the
   1.232 +status daemon needs to perform a normal status scan so that it has a
   1.233 +baseline against which to apply later updates from the kernel.
   1.234 +However, <emphasis>every</emphasis> subsequent command that does any kind of status
   1.235 +check should be noticeably faster on repositories of even fairly
   1.236 +modest size.  Better yet, the bigger your repository is, the greater a
   1.237 +performance advantage you'll see.  The <literal role="hg-ext">inotify</literal> daemon makes
   1.238 +status operations almost instantaneous on repositories of all sizes!
   1.239 +</para>
   1.240 +
   1.241 +<para>If you like, you can manually start a status daemon using the
   1.242 +<command role="hg-ext-inotify">inserve</command> command.  This gives you slightly finer
   1.243 +control over how the daemon ought to run.  This command will of course
   1.244 +only be available when the <literal role="hg-ext">inotify</literal> extension is enabled.
   1.245 +</para>
   1.246 +
   1.247 +<para>When you're using the <literal role="hg-ext">inotify</literal> extension, you should notice
   1.248 +<emphasis>no difference at all</emphasis> in Mercurial's behaviour, with the sole
   1.249 +exception of status-related commands running a whole lot faster than
   1.250 +they used to.  You should specifically expect that commands will not
   1.251 +print different output; neither should they give different results.
   1.252 +If either of these situations occurs, please report a bug.
   1.253 +</para>
   1.254 +
   1.255 +</sect1>
   1.256 +<sect1>
   1.257 +<title>Flexible diff support with the <literal role="hg-ext">extdiff</literal> extension</title>
   1.258 +<para>\label{sec:hgext:extdiff}
   1.259 +</para>
   1.260 +
   1.261 +<para>Mercurial's built-in <command role="hg-cmd">hg diff</command> command outputs plaintext unified
   1.262 +diffs.
   1.263 +<!-- &interaction.extdiff.diff; -->
   1.264 +If you would like to use an external tool to display modifications,
   1.265 +you'll want to use the <literal role="hg-ext">extdiff</literal> extension.  This will let you
   1.266 +use, for example, a graphical diff tool.
   1.267 +</para>
   1.268 +
   1.269 +<para>The <literal role="hg-ext">extdiff</literal> extension is bundled with Mercurial, so it's easy
   1.270 +to set up.  In the <literal role="rc-extensions">extensions</literal> section of your <filename role="special"> /.hgrc</filename>,
   1.271 +simply add a one-line entry to enable the extension.
   1.272 +</para>
   1.273 +<programlisting>
   1.274 +<para>  [extensions]
   1.275 +  extdiff =
   1.276 +</para>
   1.277 +</programlisting>
   1.278 +<para>This introduces a command named <command role="hg-ext-extdiff">extdiff</command>, which by
   1.279 +default uses your system's <command>diff</command> command to generate a
   1.280 +unified diff in the same form as the built-in <command role="hg-cmd">hg diff</command> command.
   1.281 +<!-- &interaction.extdiff.extdiff; -->
   1.282 +The result won't be exactly the same as with the built-in <command role="hg-cmd">hg diff</command>
   1.283 +variations, because the output of <command>diff</command> varies from one
   1.284 +system to another, even when passed the same options.
   1.285 +</para>
   1.286 +
   1.287 +<para>As the <quote><literal>making snapshot</literal></quote> lines of output above imply, the
   1.288 +<command role="hg-ext-extdiff">extdiff</command> command works by creating two snapshots of
   1.289 +your source tree.  The first snapshot is of the source revision; the
   1.290 +second, of the target revision or working directory.  The
   1.291 +<command role="hg-ext-extdiff">extdiff</command> command generates these snapshots in a
   1.292 +temporary directory, passes the name of each directory to an external
   1.293 +diff viewer, then deletes the temporary directory.  For efficiency, it
   1.294 +only snapshots the directories and files that have changed between the
   1.295 +two revisions.
   1.296 +</para>
   1.297 +
   1.298 +<para>Snapshot directory names have the same base name as your repository.
   1.299 +If your repository path is <filename class="directory">/quux/bar/foo</filename>, then <filename class="directory">foo</filename>
   1.300 +will be the name of each snapshot directory.  Each snapshot directory
   1.301 +name has its changeset ID appended, if appropriate.  If a snapshot is
   1.302 +of revision <literal>a631aca1083f</literal>, the directory will be named
   1.303 +<filename class="directory">foo.a631aca1083f</filename>.  A snapshot of the working directory won't
   1.304 +have a changeset ID appended, so it would just be <filename class="directory">foo</filename> in
   1.305 +this example.  To see what this looks like in practice, look again at
   1.306 +the <command role="hg-ext-extdiff">extdiff</command> example above.  Notice that the diff has
   1.307 +the snapshot directory names embedded in its header.
   1.308 +</para>
   1.309 +
   1.310 +<para>The <command role="hg-ext-extdiff">extdiff</command> command accepts two important options.
   1.311 +The <option role="hg-ext-extdiff-cmd-extdiff-opt">-p</option> option lets you choose a program to
   1.312 +view differences with, instead of <command>diff</command>.  With the
   1.313 +<option role="hg-ext-extdiff-cmd-extdiff-opt">-o</option> option, you can change the options that
   1.314 +<command role="hg-ext-extdiff">extdiff</command> passes to the program (by default, these
   1.315 +options are <quote><literal>-Npru</literal></quote>, which only make sense if you're
   1.316 +running <command>diff</command>).  In other respects, the
   1.317 +<command role="hg-ext-extdiff">extdiff</command> command acts similarly to the built-in
   1.318 +<command role="hg-cmd">hg diff</command> command: you use the same option names, syntax, and
   1.319 +arguments to specify the revisions you want, the files you want, and
   1.320 +so on.
   1.321 +</para>
   1.322 +
   1.323 +<para>As an example, here's how to run the normal system <command>diff</command>
   1.324 +command, getting it to generate context diffs (using the
   1.325 +<option role="cmd-opt-diff">-c</option> option) instead of unified diffs, and five lines of
   1.326 +context instead of the default three (passing <literal>5</literal> as the
   1.327 +argument to the <option role="cmd-opt-diff">-C</option> option).
   1.328 +<!-- &interaction.extdiff.extdiff-ctx; -->
   1.329 +</para>
   1.330 +
   1.331 +<para>Launching a visual diff tool is just as easy.  Here's how to launch
   1.332 +the <command>kdiff3</command> viewer.
   1.333 +</para>
   1.334 +<programlisting>
   1.335 +<para>  hg extdiff -p kdiff3 -o </quote>
   1.336 +</para>
   1.337 +</programlisting>
   1.338 +
   1.339 +<para>If your diff viewing command can't deal with directories, you can
   1.340 +easily work around this with a little scripting.  For an example of
   1.341 +such scripting in action with the <literal role="hg-ext">mq</literal> extension and the
   1.342 +<command>interdiff</command> command, see
   1.343 +section <xref linkend="mq-collab:tips:interdiff"/>.
   1.344 +</para>
   1.345 +
   1.346 +<sect2>
   1.347 +<title>Defining command aliases</title>
   1.348 +
   1.349 +<para>It can be cumbersome to remember the options to both the
   1.350 +<command role="hg-ext-extdiff">extdiff</command> command and the diff viewer you want to use,
   1.351 +so the <literal role="hg-ext">extdiff</literal> extension lets you define <emphasis>new</emphasis> commands
   1.352 +that will invoke your diff viewer with exactly the right options.
   1.353 +</para>
   1.354 +
   1.355 +<para>All you need to do is edit your <filename role="special"> /.hgrc</filename>, and add a section named
   1.356 +<literal role="rc-extdiff">extdiff</literal>.  Inside this section, you can define multiple
   1.357 +commands.  Here's how to add a <literal>kdiff3</literal> command.  Once you've
   1.358 +defined this, you can type <quote><literal>hg kdiff3</literal></quote> and the
   1.359 +<literal role="hg-ext">extdiff</literal> extension will run <command>kdiff3</command> for you.
   1.360 +</para>
   1.361 +<programlisting>
   1.362 +<para>  [extdiff]
   1.363 +  cmd.kdiff3 =
   1.364 +</para>
   1.365 +</programlisting>
   1.366 +<para>If you leave the right hand side of the definition empty, as above,
   1.367 +the <literal role="hg-ext">extdiff</literal> extension uses the name of the command you defined
   1.368 +as the name of the external program to run.  But these names don't
   1.369 +have to be the same.  Here, we define a command named <quote>\texttt{hg
   1.370 +  wibble}</quote>, which runs <command>kdiff3</command>.
   1.371 +</para>
   1.372 +<programlisting>
   1.373 +<para>  [extdiff]
   1.374 +  cmd.wibble = kdiff3
   1.375 +</para>
   1.376 +</programlisting>
   1.377 +
   1.378 +<para>You can also specify the default options that you want to invoke your
   1.379 +diff viewing program with.  The prefix to use is <quote><literal>opts.</literal></quote>,
   1.380 +followed by the name of the command to which the options apply.  This
   1.381 +example defines a <quote><literal>hg vimdiff</literal></quote> command that runs the
   1.382 +<command>vim</command> editor's <literal>DirDiff</literal> extension.
   1.383 +</para>
   1.384 +<programlisting>
   1.385 +<para>  [extdiff]
   1.386 +  cmd.vimdiff = vim
   1.387 +  opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
   1.388 +</para>
   1.389 +</programlisting>
   1.390 +
   1.391 +</sect2>
   1.392 +</sect1>
   1.393 +<sect1>
   1.394 +<title>Cherrypicking changes with the <literal role="hg-ext">transplant</literal> extension</title>
   1.395 +<para>\label{sec:hgext:transplant}
   1.396 +</para>
   1.397 +
   1.398 +<para>Need to have a long chat with Brendan about this.
   1.399 +</para>
   1.400 +
   1.401 +</sect1>
   1.402 +<sect1>
   1.403 +<title>Send changes via email with the <literal role="hg-ext">patchbomb</literal> extension</title>
   1.404 +<para>\label{sec:hgext:patchbomb}
   1.405 +</para>
   1.406 +
   1.407 +<para>Many projects have a culture of <quote>change review</quote>, in which people
   1.408 +send their modifications to a mailing list for others to read and
   1.409 +comment on before they commit the final version to a shared
   1.410 +repository.  Some projects have people who act as gatekeepers; they
   1.411 +apply changes from other people to a repository to which those others
   1.412 +don't have access.
   1.413 +</para>
   1.414 +
   1.415 +<para>Mercurial makes it easy to send changes over email for review or
   1.416 +application, via its <literal role="hg-ext">patchbomb</literal> extension.  The extension is so
   1.417 +namd because changes are formatted as patches, and it's usual to send
   1.418 +one changeset per email message.  Sending a long series of changes by
   1.419 +email is thus much like <quote>bombing</quote> the recipient's inbox, hence
   1.420 +<quote>patchbomb</quote>.
   1.421 +</para>
   1.422 +
   1.423 +<para>As usual, the basic configuration of the <literal role="hg-ext">patchbomb</literal> extension
   1.424 +takes just one or two lines in your <filename role="special"> /.hgrc</filename>.
   1.425 +</para>
   1.426 +<programlisting>
   1.427 +<para>  [extensions]
   1.428 +  patchbomb =
   1.429 +</para>
   1.430 +</programlisting>
   1.431 +<para>Once you've enabled the extension, you will have a new command
   1.432 +available, named <command role="hg-ext-patchbomb">email</command>.
   1.433 +</para>
   1.434 +
   1.435 +<para>The safest and best way to invoke the <command role="hg-ext-patchbomb">email</command>
   1.436 +command is to <emphasis>always</emphasis> run it first with the
   1.437 +<option role="hg-ext-patchbomb-cmd-email-opt">-n</option> option.  This will show you what the
   1.438 +command <emphasis>would</emphasis> send, without actually sending anything.  Once
   1.439 +you've had a quick glance over the changes and verified that you are
   1.440 +sending the right ones, you can rerun the same command, with the
   1.441 +<option role="hg-ext-patchbomb-cmd-email-opt">-n</option> option removed.
   1.442 +</para>
   1.443 +
   1.444 +<para>The <command role="hg-ext-patchbomb">email</command> command accepts the same kind of
   1.445 +revision syntax as every other Mercurial command.  For example, this
   1.446 +command will send every revision between 7 and <literal>tip</literal>,
   1.447 +inclusive.
   1.448 +</para>
   1.449 +<programlisting>
   1.450 +<para>  hg email -n 7:tip
   1.451 +</para>
   1.452 +</programlisting>
   1.453 +<para>You can also specify a <emphasis>repository</emphasis> to compare with.  If you
   1.454 +provide a repository but no revisions, the <command role="hg-ext-patchbomb">email</command>
   1.455 +command will send all revisions in the local repository that are not
   1.456 +present in the remote repository.  If you additionally specify
   1.457 +revisions or a branch name (the latter using the
   1.458 +<option role="hg-ext-patchbomb-cmd-email-opt">-b</option> option), this will constrain the
   1.459 +revisions sent.
   1.460 +</para>
   1.461 +
   1.462 +<para>It's perfectly safe to run the <command role="hg-ext-patchbomb">email</command> command
   1.463 +without the names of the people you want to send to: if you do this,
   1.464 +it will just prompt you for those values interactively.  (If you're
   1.465 +using a Linux or Unix-like system, you should have enhanced
   1.466 +<literal>readline</literal>-style editing capabilities when entering those
   1.467 +headers, too, which is useful.)
   1.468 +</para>
   1.469 +
   1.470 +<para>When you are sending just one revision, the <command role="hg-ext-patchbomb">email</command>
   1.471 +command will by default use the first line of the changeset
   1.472 +description as the subject of the single email message it sends.
   1.473 +</para>
   1.474 +
   1.475 +<para>If you send multiple revisions, the <command role="hg-ext-patchbomb">email</command> command
   1.476 +will usually send one message per changeset.  It will preface the
   1.477 +series with an introductory message, in which you should describe the
   1.478 +purpose of the series of changes you're sending.
   1.479 +</para>
   1.480 +
   1.481 +<sect2>
   1.482 +<title>Changing the behaviour of patchbombs</title>
   1.483 +
   1.484 +<para>Not every project has exactly the same conventions for sending changes
   1.485 +in email; the <literal role="hg-ext">patchbomb</literal> extension tries to accommodate a
   1.486 +number of variations through command line options.
   1.487 +</para>
   1.488 +<itemizedlist>
   1.489 +<listitem><para>You can write a subject for the introductory message on the
   1.490 +  command line using the <option role="hg-ext-patchbomb-cmd-email-opt">-s</option> option.  This
   1.491 +  takes one argument, the text of the subject to use.
   1.492 +</para>
   1.493 +</listitem>
   1.494 +<listitem><para>To change the email address from which the messages originate,
   1.495 +  use the <option role="hg-ext-patchbomb-cmd-email-opt">-f</option> option.  This takes one
   1.496 +  argument, the email address to use.
   1.497 +</para>
   1.498 +</listitem>
   1.499 +<listitem><para>The default behaviour is to send unified diffs (see
   1.500 +  section <xref linkend="sec:mq:patch"/> for a description of the format), one per
   1.501 +  message.  You can send a binary bundle instead with the
   1.502 +  <option role="hg-ext-patchbomb-cmd-email-opt">-b</option> option.
   1.503 +</para>
   1.504 +</listitem>
   1.505 +<listitem><para>Unified diffs are normally prefaced with a metadata header.  You
   1.506 +  can omit this, and send unadorned diffs, with the
   1.507 +  <option role="hg-ext-patchbomb-cmd-email-opt">--plain</option> option.
   1.508 +</para>
   1.509 +</listitem>
   1.510 +<listitem><para>Diffs are normally sent <quote>inline</quote>, in the same body part as the
   1.511 +  description of a patch.  This makes it easiest for the largest
   1.512 +  number of readers to quote and respond to parts of a diff, as some
   1.513 +  mail clients will only quote the first MIME body part in a message.
   1.514 +  If you'd prefer to send the description and the diff in separate
   1.515 +  body parts, use the <option role="hg-ext-patchbomb-cmd-email-opt">-a</option> option.
   1.516 +</para>
   1.517 +</listitem>
   1.518 +<listitem><para>Instead of sending mail messages, you can write them to an
   1.519 +  <literal>mbox</literal>-format mail folder using the
   1.520 +  <option role="hg-ext-patchbomb-cmd-email-opt">-m</option> option.  That option takes one
   1.521 +  argument, the name of the file to write to.
   1.522 +</para>
   1.523 +</listitem>
   1.524 +<listitem><para>If you would like to add a <command>diffstat</command>-format summary to
   1.525 +  each patch, and one to the introductory message, use the
   1.526 +  <option role="hg-ext-patchbomb-cmd-email-opt">-d</option> option.  The <command>diffstat</command>
   1.527 +  command displays a table containing the name of each file patched,
   1.528 +  the number of lines affected, and a histogram showing how much each
   1.529 +  file is modified.  This gives readers a qualitative glance at how
   1.530 +  complex a patch is.
   1.531 +</para>
   1.532 +</listitem></itemizedlist>
   1.533 +
   1.534 +</sect2>
   1.535 +</sect1>
   1.536 +</chapter>
   1.537 +
   1.538 +<!--
   1.539 +local variables: 
   1.540 +sgml-parent-document: ("00book.xml" "book" "chapter")
   1.541 +end:
   1.542 +-->
   1.543 \ No newline at end of file