| 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:
|
