| rev |
line source |
|
bos@559
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
|
bos@559
|
2
|
|
bos@559
|
3 <chapter id="chap:hook">
|
|
bos@572
|
4 <?dbhtml filename="handling-repository-events-with-hooks.html"?>
|
|
bos@559
|
5 <title>Handling repository events with hooks</title>
|
|
bos@559
|
6
|
|
bos@559
|
7 <para>Mercurial offers a powerful mechanism to let you perform
|
|
bos@559
|
8 automated actions in response to events that occur in a
|
|
bos@559
|
9 repository. In some cases, you can even control Mercurial's
|
|
bos@559
|
10 response to those events.</para>
|
|
bos@559
|
11
|
|
bos@559
|
12 <para>The name Mercurial uses for one of these actions is a
|
|
bos@559
|
13 <emphasis>hook</emphasis>. Hooks are called
|
|
bos@559
|
14 <quote>triggers</quote> in some revision control systems, but the
|
|
bos@559
|
15 two names refer to the same idea.</para>
|
|
bos@559
|
16
|
|
bos@559
|
17 <sect1>
|
|
bos@559
|
18 <title>An overview of hooks in Mercurial</title>
|
|
bos@559
|
19
|
|
bos@559
|
20 <para>Here is a brief list of the hooks that Mercurial supports.
|
|
bos@559
|
21 We will revisit each of these hooks in more detail later, in
|
|
bos@559
|
22 section <xref linkend="sec:hook:ref"/>.</para>
|
|
bos@559
|
23
|
|
bos@559
|
24 <itemizedlist>
|
|
bos@559
|
25 <listitem><para><literal role="hook">changegroup</literal>: This
|
|
bos@559
|
26 is run after a group of changesets has been brought into the
|
|
bos@559
|
27 repository from elsewhere.</para>
|
|
bos@559
|
28 </listitem>
|
|
bos@559
|
29 <listitem><para><literal role="hook">commit</literal>: This is
|
|
bos@559
|
30 run after a new changeset has been created in the local
|
|
bos@559
|
31 repository.</para>
|
|
bos@559
|
32 </listitem>
|
|
bos@559
|
33 <listitem><para><literal role="hook">incoming</literal>: This is
|
|
bos@559
|
34 run once for each new changeset that is brought into the
|
|
bos@559
|
35 repository from elsewhere. Notice the difference from
|
|
bos@559
|
36 <literal role="hook">changegroup</literal>, which is run
|
|
bos@559
|
37 once per <emphasis>group</emphasis> of changesets brought
|
|
bos@559
|
38 in.</para>
|
|
bos@559
|
39 </listitem>
|
|
bos@559
|
40 <listitem><para><literal role="hook">outgoing</literal>: This is
|
|
bos@559
|
41 run after a group of changesets has been transmitted from
|
|
bos@559
|
42 this repository.</para>
|
|
bos@559
|
43 </listitem>
|
|
bos@559
|
44 <listitem><para><literal role="hook">prechangegroup</literal>:
|
|
bos@559
|
45 This is run before starting to bring a group of changesets
|
|
bos@559
|
46 into the repository.
|
|
bos@559
|
47 </para>
|
|
bos@559
|
48 </listitem>
|
|
bos@559
|
49 <listitem><para><literal role="hook">precommit</literal>:
|
|
bos@559
|
50 Controlling. This is run before starting a commit.
|
|
bos@559
|
51 </para>
|
|
bos@559
|
52 </listitem>
|
|
bos@559
|
53 <listitem><para><literal role="hook">preoutgoing</literal>:
|
|
bos@559
|
54 Controlling. This is run before starting to transmit a group
|
|
bos@559
|
55 of changesets from this repository.
|
|
bos@559
|
56 </para>
|
|
bos@559
|
57 </listitem>
|
|
bos@559
|
58 <listitem><para><literal role="hook">pretag</literal>:
|
|
bos@559
|
59 Controlling. This is run before creating a tag.
|
|
bos@559
|
60 </para>
|
|
bos@559
|
61 </listitem>
|
|
bos@559
|
62 <listitem><para><literal
|
|
bos@559
|
63 role="hook">pretxnchangegroup</literal>: Controlling. This
|
|
bos@559
|
64 is run after a group of changesets has been brought into the
|
|
bos@559
|
65 local repository from another, but before the transaction
|
|
bos@559
|
66 completes that will make the changes permanent in the
|
|
bos@559
|
67 repository.
|
|
bos@559
|
68 </para>
|
|
bos@559
|
69 </listitem>
|
|
bos@559
|
70 <listitem><para><literal role="hook">pretxncommit</literal>:
|
|
bos@559
|
71 Controlling. This is run after a new changeset has been
|
|
bos@559
|
72 created in the local repository, but before the transaction
|
|
bos@559
|
73 completes that will make it permanent.
|
|
bos@559
|
74 </para>
|
|
bos@559
|
75 </listitem>
|
|
bos@559
|
76 <listitem><para><literal role="hook">preupdate</literal>:
|
|
bos@559
|
77 Controlling. This is run before starting an update or merge
|
|
bos@559
|
78 of the working directory.
|
|
bos@559
|
79 </para>
|
|
bos@559
|
80 </listitem>
|
|
bos@559
|
81 <listitem><para><literal role="hook">tag</literal>: This is run
|
|
bos@559
|
82 after a tag is created.
|
|
bos@559
|
83 </para>
|
|
bos@559
|
84 </listitem>
|
|
bos@559
|
85 <listitem><para><literal role="hook">update</literal>: This is
|
|
bos@559
|
86 run after an update or merge of the working directory has
|
|
bos@559
|
87 finished.
|
|
bos@559
|
88 </para>
|
|
bos@559
|
89 </listitem></itemizedlist>
|
|
bos@559
|
90 <para>Each of the hooks whose description begins with the word
|
|
bos@559
|
91 <quote>Controlling</quote> has the ability to determine whether
|
|
bos@559
|
92 an activity can proceed. If the hook succeeds, the activity may
|
|
bos@559
|
93 proceed; if it fails, the activity is either not permitted or
|
|
bos@559
|
94 undone, depending on the hook.
|
|
bos@559
|
95 </para>
|
|
bos@559
|
96
|
|
bos@559
|
97 </sect1>
|
|
bos@559
|
98 <sect1>
|
|
bos@559
|
99 <title>Hooks and security</title>
|
|
bos@559
|
100
|
|
bos@559
|
101 <sect2>
|
|
bos@559
|
102 <title>Hooks are run with your privileges</title>
|
|
bos@559
|
103
|
|
bos@559
|
104 <para>When you run a Mercurial command in a repository, and the
|
|
bos@559
|
105 command causes a hook to run, that hook runs on
|
|
bos@559
|
106 <emphasis>your</emphasis> system, under
|
|
bos@559
|
107 <emphasis>your</emphasis> user account, with
|
|
bos@559
|
108 <emphasis>your</emphasis> privilege level. Since hooks are
|
|
bos@559
|
109 arbitrary pieces of executable code, you should treat them
|
|
bos@559
|
110 with an appropriate level of suspicion. Do not install a hook
|
|
bos@559
|
111 unless you are confident that you know who created it and what
|
|
bos@559
|
112 it does.
|
|
bos@559
|
113 </para>
|
|
bos@559
|
114
|
|
bos@559
|
115 <para>In some cases, you may be exposed to hooks that you did
|
|
bos@559
|
116 not install yourself. If you work with Mercurial on an
|
|
bos@559
|
117 unfamiliar system, Mercurial will run hooks defined in that
|
|
bos@559
|
118 system's global <filename role="special"> /.hgrc</filename>\
|
|
bos@559
|
119 file.
|
|
bos@559
|
120 </para>
|
|
bos@559
|
121
|
|
bos@559
|
122 <para>If you are working with a repository owned by another
|
|
bos@559
|
123 user, Mercurial can run hooks defined in that user's
|
|
bos@559
|
124 repository, but it will still run them as <quote>you</quote>.
|
|
bos@559
|
125 For example, if you <command role="hg-cmd">hg pull</command>
|
|
bos@559
|
126 from that repository, and its <filename
|
|
bos@559
|
127 role="special">.hg/hgrc</filename> defines a local <literal
|
|
bos@559
|
128 role="hook">outgoing</literal> hook, that hook will run
|
|
bos@559
|
129 under your user account, even though you don't own that
|
|
bos@559
|
130 repository.
|
|
bos@559
|
131 </para>
|
|
bos@559
|
132
|
|
bos@559
|
133 <note>
|
|
bos@559
|
134 <para> This only applies if you are pulling from a repository
|
|
bos@559
|
135 on a local or network filesystem. If you're pulling over
|
|
bos@559
|
136 http or ssh, any <literal role="hook">outgoing</literal>
|
|
bos@559
|
137 hook will run under whatever account is executing the server
|
|
bos@559
|
138 process, on the server.
|
|
bos@559
|
139 </para>
|
|
bos@559
|
140 </note>
|
|
bos@559
|
141
|
|
bos@559
|
142 <para>XXX To see what hooks are defined in a repository, use the
|
|
bos@559
|
143 <command role="hg-cmd">hg config hooks</command> command. If
|
|
bos@559
|
144 you are working in one repository, but talking to another that
|
|
bos@559
|
145 you do not own (e.g. using <command role="hg-cmd">hg
|
|
bos@559
|
146 pull</command> or <command role="hg-cmd">hg
|
|
bos@559
|
147 incoming</command>), remember that it is the other
|
|
bos@559
|
148 repository's hooks you should be checking, not your own.
|
|
bos@559
|
149 </para>
|
|
bos@559
|
150
|
|
bos@559
|
151 </sect2>
|
|
bos@559
|
152 <sect2>
|
|
bos@559
|
153 <title>Hooks do not propagate</title>
|
|
bos@559
|
154
|
|
bos@559
|
155 <para>In Mercurial, hooks are not revision controlled, and do
|
|
bos@559
|
156 not propagate when you clone, or pull from, a repository. The
|
|
bos@559
|
157 reason for this is simple: a hook is a completely arbitrary
|
|
bos@559
|
158 piece of executable code. It runs under your user identity,
|
|
bos@559
|
159 with your privilege level, on your machine.
|
|
bos@559
|
160 </para>
|
|
bos@559
|
161
|
|
bos@559
|
162 <para>It would be extremely reckless for any distributed
|
|
bos@559
|
163 revision control system to implement revision-controlled
|
|
bos@559
|
164 hooks, as this would offer an easily exploitable way to
|
|
bos@559
|
165 subvert the accounts of users of the revision control system.
|
|
bos@559
|
166 </para>
|
|
bos@559
|
167
|
|
bos@559
|
168 <para>Since Mercurial does not propagate hooks, if you are
|
|
bos@559
|
169 collaborating with other people on a common project, you
|
|
bos@559
|
170 should not assume that they are using the same Mercurial hooks
|
|
bos@559
|
171 as you are, or that theirs are correctly configured. You
|
|
bos@559
|
172 should document the hooks you expect people to use.
|
|
bos@559
|
173 </para>
|
|
bos@559
|
174
|
|
bos@559
|
175 <para>In a corporate intranet, this is somewhat easier to
|
|
bos@559
|
176 control, as you can for example provide a
|
|
bos@559
|
177 <quote>standard</quote> installation of Mercurial on an NFS
|
|
bos@559
|
178 filesystem, and use a site-wide <filename role="special">
|
|
bos@559
|
179 /.hgrc</filename>\ file to define hooks that all users will
|
|
bos@559
|
180 see. However, this too has its limits; see below.
|
|
bos@559
|
181 </para>
|
|
bos@559
|
182
|
|
bos@559
|
183 </sect2>
|
|
bos@559
|
184 <sect2>
|
|
bos@559
|
185 <title>Hooks can be overridden</title>
|
|
bos@559
|
186
|
|
bos@559
|
187 <para>Mercurial allows you to override a hook definition by
|
|
bos@559
|
188 redefining the hook. You can disable it by setting its value
|
|
bos@559
|
189 to the empty string, or change its behaviour as you wish.
|
|
bos@559
|
190 </para>
|
|
bos@559
|
191
|
|
bos@559
|
192 <para>If you deploy a system- or site-wide <filename
|
|
bos@559
|
193 role="special"> /.hgrc</filename>\ file that defines some
|
|
bos@559
|
194 hooks, you should thus understand that your users can disable
|
|
bos@559
|
195 or override those hooks.
|
|
bos@559
|
196 </para>
|
|
bos@559
|
197
|
|
bos@559
|
198 </sect2>
|
|
bos@559
|
199 <sect2>
|
|
bos@559
|
200 <title>Ensuring that critical hooks are run</title>
|
|
bos@559
|
201
|
|
bos@559
|
202 <para>Sometimes you may want to enforce a policy that you do not
|
|
bos@559
|
203 want others to be able to work around. For example, you may
|
|
bos@559
|
204 have a requirement that every changeset must pass a rigorous
|
|
bos@559
|
205 set of tests. Defining this requirement via a hook in a
|
|
bos@559
|
206 site-wide <filename role="special"> /.hgrc</filename>\ won't
|
|
bos@559
|
207 work for remote users on laptops, and of course local users
|
|
bos@559
|
208 can subvert it at will by overriding the hook.
|
|
bos@559
|
209 </para>
|
|
bos@559
|
210
|
|
bos@559
|
211 <para>Instead, you can set up your policies for use of Mercurial
|
|
bos@559
|
212 so that people are expected to propagate changes through a
|
|
bos@559
|
213 well-known <quote>canonical</quote> server that you have
|
|
bos@559
|
214 locked down and configured appropriately.
|
|
bos@559
|
215 </para>
|
|
bos@559
|
216
|
|
bos@559
|
217 <para>One way to do this is via a combination of social
|
|
bos@559
|
218 engineering and technology. Set up a restricted-access
|
|
bos@559
|
219 account; users can push changes over the network to
|
|
bos@559
|
220 repositories managed by this account, but they cannot log into
|
|
bos@559
|
221 the account and run normal shell commands. In this scenario,
|
|
bos@559
|
222 a user can commit a changeset that contains any old garbage
|
|
bos@559
|
223 they want.
|
|
bos@559
|
224 </para>
|
|
bos@559
|
225
|
|
bos@559
|
226 <para>When someone pushes a changeset to the server that
|
|
bos@559
|
227 everyone pulls from, the server will test the changeset before
|
|
bos@559
|
228 it accepts it as permanent, and reject it if it fails to pass
|
|
bos@559
|
229 the test suite. If people only pull changes from this
|
|
bos@559
|
230 filtering server, it will serve to ensure that all changes
|
|
bos@559
|
231 that people pull have been automatically vetted.
|
|
bos@559
|
232 </para>
|
|
bos@559
|
233
|
|
bos@559
|
234 </sect2>
|
|
bos@559
|
235 </sect1>
|
|
bos@559
|
236 <sect1>
|
|
bos@559
|
237 <title>Care with <literal>pretxn</literal> hooks in a
|
|
bos@559
|
238 shared-access repository</title>
|
|
bos@559
|
239
|
|
bos@559
|
240 <para>If you want to use hooks to do some automated work in a
|
|
bos@559
|
241 repository that a number of people have shared access to, you
|
|
bos@559
|
242 need to be careful in how you do this.
|
|
bos@559
|
243 </para>
|
|
bos@559
|
244
|
|
bos@559
|
245 <para>Mercurial only locks a repository when it is writing to the
|
|
bos@559
|
246 repository, and only the parts of Mercurial that write to the
|
|
bos@559
|
247 repository pay attention to locks. Write locks are necessary to
|
|
bos@559
|
248 prevent multiple simultaneous writers from scribbling on each
|
|
bos@559
|
249 other's work, corrupting the repository.
|
|
bos@559
|
250 </para>
|
|
bos@559
|
251
|
|
bos@559
|
252 <para>Because Mercurial is careful with the order in which it
|
|
bos@559
|
253 reads and writes data, it does not need to acquire a lock when
|
|
bos@559
|
254 it wants to read data from the repository. The parts of
|
|
bos@559
|
255 Mercurial that read from the repository never pay attention to
|
|
bos@559
|
256 locks. This lockless reading scheme greatly increases
|
|
bos@559
|
257 performance and concurrency.
|
|
bos@559
|
258 </para>
|
|
bos@559
|
259
|
|
bos@559
|
260 <para>With great performance comes a trade-off, though, one which
|
|
bos@559
|
261 has the potential to cause you trouble unless you're aware of
|
|
bos@559
|
262 it. To describe this requires a little detail about how
|
|
bos@559
|
263 Mercurial adds changesets to a repository and reads those
|
|
bos@559
|
264 changes.
|
|
bos@559
|
265 </para>
|
|
bos@559
|
266
|
|
bos@559
|
267 <para>When Mercurial <emphasis>writes</emphasis> metadata, it
|
|
bos@559
|
268 writes it straight into the destination file. It writes file
|
|
bos@559
|
269 data first, then manifest data (which contains pointers to the
|
|
bos@559
|
270 new file data), then changelog data (which contains pointers to
|
|
bos@559
|
271 the new manifest data). Before the first write to each file, it
|
|
bos@559
|
272 stores a record of where the end of the file was in its
|
|
bos@559
|
273 transaction log. If the transaction must be rolled back,
|
|
bos@559
|
274 Mercurial simply truncates each file back to the size it was
|
|
bos@559
|
275 before the transaction began.
|
|
bos@559
|
276 </para>
|
|
bos@559
|
277
|
|
bos@559
|
278 <para>When Mercurial <emphasis>reads</emphasis> metadata, it reads
|
|
bos@559
|
279 the changelog first, then everything else. Since a reader will
|
|
bos@559
|
280 only access parts of the manifest or file metadata that it can
|
|
bos@559
|
281 see in the changelog, it can never see partially written data.
|
|
bos@559
|
282 </para>
|
|
bos@559
|
283
|
|
bos@559
|
284 <para>Some controlling hooks (<literal
|
|
bos@559
|
285 role="hook">pretxncommit</literal> and <literal
|
|
bos@559
|
286 role="hook">pretxnchangegroup</literal>) run when a
|
|
bos@559
|
287 transaction is almost complete. All of the metadata has been
|
|
bos@559
|
288 written, but Mercurial can still roll the transaction back and
|
|
bos@559
|
289 cause the newly-written data to disappear.
|
|
bos@559
|
290 </para>
|
|
bos@559
|
291
|
|
bos@559
|
292 <para>If one of these hooks runs for long, it opens a window of
|
|
bos@559
|
293 time during which a reader can see the metadata for changesets
|
|
bos@559
|
294 that are not yet permanent, and should not be thought of as
|
|
bos@559
|
295 <quote>really there</quote>. The longer the hook runs, the
|
|
bos@559
|
296 longer that window is open.
|
|
bos@559
|
297 </para>
|
|
bos@559
|
298
|
|
bos@559
|
299 <sect2>
|
|
bos@559
|
300 <title>The problem illustrated</title>
|
|
bos@559
|
301
|
|
bos@559
|
302 <para>In principle, a good use for the <literal
|
|
bos@559
|
303 role="hook">pretxnchangegroup</literal> hook would be to
|
|
bos@559
|
304 automatically build and test incoming changes before they are
|
|
bos@559
|
305 accepted into a central repository. This could let you
|
|
bos@559
|
306 guarantee that nobody can push changes to this repository that
|
|
bos@559
|
307 <quote>break the build</quote>. But if a client can pull
|
|
bos@559
|
308 changes while they're being tested, the usefulness of the test
|
|
bos@559
|
309 is zero; an unsuspecting someone can pull untested changes,
|
|
bos@559
|
310 potentially breaking their build.
|
|
bos@559
|
311 </para>
|
|
bos@559
|
312
|
|
bos@559
|
313 <para>The safest technological answer to this challenge is to
|
|
bos@559
|
314 set up such a <quote>gatekeeper</quote> repository as
|
|
bos@559
|
315 <emphasis>unidirectional</emphasis>. Let it take changes
|
|
bos@559
|
316 pushed in from the outside, but do not allow anyone to pull
|
|
bos@559
|
317 changes from it (use the <literal
|
|
bos@559
|
318 role="hook">preoutgoing</literal> hook to lock it down).
|
|
bos@559
|
319 Configure a <literal role="hook">changegroup</literal> hook so
|
|
bos@559
|
320 that if a build or test succeeds, the hook will push the new
|
|
bos@559
|
321 changes out to another repository that people
|
|
bos@559
|
322 <emphasis>can</emphasis> pull from.
|
|
bos@559
|
323 </para>
|
|
bos@559
|
324
|
|
bos@559
|
325 <para>In practice, putting a centralised bottleneck like this in
|
|
bos@559
|
326 place is not often a good idea, and transaction visibility has
|
|
bos@559
|
327 nothing to do with the problem. As the size of a
|
|
bos@559
|
328 project&emdash;and the time it takes to build and
|
|
bos@559
|
329 test&emdash;grows, you rapidly run into a wall with this
|
|
bos@559
|
330 <quote>try before you buy</quote> approach, where you have
|
|
bos@559
|
331 more changesets to test than time in which to deal with them.
|
|
bos@559
|
332 The inevitable result is frustration on the part of all
|
|
bos@559
|
333 involved.
|
|
bos@559
|
334 </para>
|
|
bos@559
|
335
|
|
bos@559
|
336 <para>An approach that scales better is to get people to build
|
|
bos@559
|
337 and test before they push, then run automated builds and tests
|
|
bos@559
|
338 centrally <emphasis>after</emphasis> a push, to be sure all is
|
|
bos@559
|
339 well. The advantage of this approach is that it does not
|
|
bos@559
|
340 impose a limit on the rate at which the repository can accept
|
|
bos@559
|
341 changes.
|
|
bos@559
|
342 </para>
|
|
bos@559
|
343
|
|
bos@559
|
344 </sect2>
|
|
bos@559
|
345 </sect1>
|
|
bos@559
|
346 <sect1 id="sec:hook:simple">
|
|
bos@559
|
347 <title>A short tutorial on using hooks</title>
|
|
bos@559
|
348
|
|
bos@559
|
349 <para>It is easy to write a Mercurial hook. Let's start with a
|
|
bos@559
|
350 hook that runs when you finish a <command role="hg-cmd">hg
|
|
bos@559
|
351 commit</command>, and simply prints the hash of the changeset
|
|
bos@559
|
352 you just created. The hook is called <literal
|
|
bos@559
|
353 role="hook">commit</literal>.
|
|
bos@559
|
354 </para>
|
|
bos@559
|
355
|
|
bos@559
|
356 <para>All hooks follow the pattern in this example.</para>
|
|
bos@559
|
357
|
|
bos@567
|
358 &interaction.hook.simple.init;
|
|
bos@559
|
359
|
|
bos@559
|
360 <para>You add an entry to the <literal
|
|
bos@559
|
361 role="rc-hooks">hooks</literal> section of your <filename
|
|
bos@559
|
362 role="special"> /.hgrc</filename>. On the left is the name of
|
|
bos@559
|
363 the event to trigger on; on the right is the action to take. As
|
|
bos@559
|
364 you can see, you can run an arbitrary shell command in a hook.
|
|
bos@559
|
365 Mercurial passes extra information to the hook using environment
|
|
bos@559
|
366 variables (look for <envar>HG_NODE</envar> in the example).
|
|
bos@559
|
367 </para>
|
|
bos@559
|
368
|
|
bos@559
|
369 <sect2>
|
|
bos@559
|
370 <title>Performing multiple actions per event</title>
|
|
bos@559
|
371
|
|
bos@559
|
372 <para>Quite often, you will want to define more than one hook
|
|
bos@559
|
373 for a particular kind of event, as shown below.</para>
|
|
bos@559
|
374
|
|
bos@567
|
375 &interaction.hook.simple.ext;
|
|
bos@559
|
376
|
|
bos@559
|
377 <para>Mercurial lets you do this by adding an
|
|
bos@559
|
378 <emphasis>extension</emphasis> to the end of a hook's name.
|
|
bos@559
|
379 You extend a hook's name by giving the name of the hook,
|
|
bos@559
|
380 followed by a full stop (the
|
|
bos@559
|
381 <quote><literal>.</literal></quote> character), followed by
|
|
bos@559
|
382 some more text of your choosing. For example, Mercurial will
|
|
bos@559
|
383 run both <literal>commit.foo</literal> and
|
|
bos@559
|
384 <literal>commit.bar</literal> when the
|
|
bos@559
|
385 <literal>commit</literal> event occurs.
|
|
bos@559
|
386 </para>
|
|
bos@559
|
387
|
|
bos@559
|
388 <para>To give a well-defined order of execution when there are
|
|
bos@559
|
389 multiple hooks defined for an event, Mercurial sorts hooks by
|
|
bos@559
|
390 extension, and executes the hook commands in this sorted
|
|
bos@559
|
391 order. In the above example, it will execute
|
|
bos@559
|
392 <literal>commit.bar</literal> before
|
|
bos@559
|
393 <literal>commit.foo</literal>, and <literal>commit</literal>
|
|
bos@559
|
394 before both.
|
|
bos@559
|
395 </para>
|
|
bos@559
|
396
|
|
bos@559
|
397 <para>It is a good idea to use a somewhat descriptive extension
|
|
bos@559
|
398 when you define a new hook. This will help you to remember
|
|
bos@559
|
399 what the hook was for. If the hook fails, you'll get an error
|
|
bos@559
|
400 message that contains the hook name and extension, so using a
|
|
bos@559
|
401 descriptive extension could give you an immediate hint as to
|
|
bos@559
|
402 why the hook failed (see section <xref
|
|
bos@559
|
403 linkend="sec:hook:perm"/> for an example).
|
|
bos@559
|
404 </para>
|
|
bos@559
|
405
|
|
bos@559
|
406 </sect2>
|
|
bos@559
|
407 <sect2 id="sec:hook:perm">
|
|
bos@559
|
408 <title>Controlling whether an activity can proceed</title>
|
|
bos@559
|
409
|
|
bos@559
|
410 <para>In our earlier examples, we used the <literal
|
|
bos@559
|
411 role="hook">commit</literal> hook, which is run after a
|
|
bos@559
|
412 commit has completed. This is one of several Mercurial hooks
|
|
bos@559
|
413 that run after an activity finishes. Such hooks have no way
|
|
bos@559
|
414 of influencing the activity itself.
|
|
bos@559
|
415 </para>
|
|
bos@559
|
416
|
|
bos@559
|
417 <para>Mercurial defines a number of events that occur before an
|
|
bos@559
|
418 activity starts; or after it starts, but before it finishes.
|
|
bos@559
|
419 Hooks that trigger on these events have the added ability to
|
|
bos@559
|
420 choose whether the activity can continue, or will abort.
|
|
bos@559
|
421 </para>
|
|
bos@559
|
422
|
|
bos@559
|
423 <para>The <literal role="hook">pretxncommit</literal> hook runs
|
|
bos@559
|
424 after a commit has all but completed. In other words, the
|
|
bos@559
|
425 metadata representing the changeset has been written out to
|
|
bos@559
|
426 disk, but the transaction has not yet been allowed to
|
|
bos@559
|
427 complete. The <literal role="hook">pretxncommit</literal>
|
|
bos@559
|
428 hook has the ability to decide whether the transaction can
|
|
bos@559
|
429 complete, or must be rolled back.
|
|
bos@559
|
430 </para>
|
|
bos@559
|
431
|
|
bos@559
|
432 <para>If the <literal role="hook">pretxncommit</literal> hook
|
|
bos@559
|
433 exits with a status code of zero, the transaction is allowed
|
|
bos@559
|
434 to complete; the commit finishes; and the <literal
|
|
bos@559
|
435 role="hook">commit</literal> hook is run. If the <literal
|
|
bos@559
|
436 role="hook">pretxncommit</literal> hook exits with a
|
|
bos@559
|
437 non-zero status code, the transaction is rolled back; the
|
|
bos@559
|
438 metadata representing the changeset is erased; and the
|
|
bos@559
|
439 <literal role="hook">commit</literal> hook is not run.
|
|
bos@559
|
440 </para>
|
|
bos@559
|
441
|
|
bos@567
|
442 &interaction.hook.simple.pretxncommit;
|
|
bos@559
|
443
|
|
bos@559
|
444 <para>The hook in the example above checks that a commit comment
|
|
bos@559
|
445 contains a bug ID. If it does, the commit can complete. If
|
|
bos@559
|
446 not, the commit is rolled back.
|
|
bos@559
|
447 </para>
|
|
bos@559
|
448
|
|
bos@559
|
449 </sect2>
|
|
bos@559
|
450 </sect1>
|
|
bos@559
|
451 <sect1>
|
|
bos@559
|
452 <title>Writing your own hooks</title>
|
|
bos@559
|
453
|
|
bos@559
|
454 <para>When you are writing a hook, you might find it useful to run
|
|
bos@559
|
455 Mercurial either with the <option
|
|
bos@559
|
456 role="hg-opt-global">-v</option> option, or the <envar
|
|
bos@559
|
457 role="rc-item-ui">verbose</envar> config item set to
|
|
bos@559
|
458 <quote>true</quote>. When you do so, Mercurial will print a
|
|
bos@559
|
459 message before it calls each hook.
|
|
bos@559
|
460 </para>
|
|
bos@559
|
461
|
|
bos@559
|
462 <sect2 id="sec:hook:lang">
|
|
bos@559
|
463 <title>Choosing how your hook should run</title>
|
|
bos@559
|
464
|
|
bos@559
|
465 <para>You can write a hook either as a normal
|
|
bos@559
|
466 program&emdash;typically a shell script&emdash;or as a Python
|
|
bos@559
|
467 function that is executed within the Mercurial process.
|
|
bos@559
|
468 </para>
|
|
bos@559
|
469
|
|
bos@559
|
470 <para>Writing a hook as an external program has the advantage
|
|
bos@559
|
471 that it requires no knowledge of Mercurial's internals. You
|
|
bos@559
|
472 can call normal Mercurial commands to get any added
|
|
bos@559
|
473 information you need. The trade-off is that external hooks
|
|
bos@559
|
474 are slower than in-process hooks.
|
|
bos@559
|
475 </para>
|
|
bos@559
|
476
|
|
bos@559
|
477 <para>An in-process Python hook has complete access to the
|
|
bos@559
|
478 Mercurial API, and does not <quote>shell out</quote> to
|
|
bos@559
|
479 another process, so it is inherently faster than an external
|
|
bos@559
|
480 hook. It is also easier to obtain much of the information
|
|
bos@559
|
481 that a hook requires by using the Mercurial API than by
|
|
bos@559
|
482 running Mercurial commands.
|
|
bos@559
|
483 </para>
|
|
bos@559
|
484
|
|
bos@559
|
485 <para>If you are comfortable with Python, or require high
|
|
bos@559
|
486 performance, writing your hooks in Python may be a good
|
|
bos@559
|
487 choice. However, when you have a straightforward hook to
|
|
bos@559
|
488 write and you don't need to care about performance (probably
|
|
bos@559
|
489 the majority of hooks), a shell script is perfectly fine.
|
|
bos@559
|
490 </para>
|
|
bos@559
|
491
|
|
bos@559
|
492 </sect2>
|
|
bos@559
|
493 <sect2 id="sec:hook:param">
|
|
bos@559
|
494 <title>Hook parameters</title>
|
|
bos@559
|
495
|
|
bos@559
|
496 <para>Mercurial calls each hook with a set of well-defined
|
|
bos@559
|
497 parameters. In Python, a parameter is passed as a keyword
|
|
bos@559
|
498 argument to your hook function. For an external program, a
|
|
bos@559
|
499 parameter is passed as an environment variable.
|
|
bos@559
|
500 </para>
|
|
bos@559
|
501
|
|
bos@559
|
502 <para>Whether your hook is written in Python or as a shell
|
|
bos@559
|
503 script, the hook-specific parameter names and values will be
|
|
bos@559
|
504 the same. A boolean parameter will be represented as a
|
|
bos@559
|
505 boolean value in Python, but as the number 1 (for
|
|
bos@559
|
506 <quote>true</quote>) or 0 (for <quote>false</quote>) as an
|
|
bos@559
|
507 environment variable for an external hook. If a hook
|
|
bos@559
|
508 parameter is named <literal>foo</literal>, the keyword
|
|
bos@559
|
509 argument for a Python hook will also be named
|
|
bos@559
|
510 <literal>foo</literal>, while the environment variable for an
|
|
bos@559
|
511 external hook will be named <literal>HG_FOO</literal>.
|
|
bos@559
|
512 </para>
|
|
bos@559
|
513
|
|
bos@559
|
514 </sect2>
|
|
bos@559
|
515 <sect2>
|
|
bos@559
|
516 <title>Hook return values and activity control</title>
|
|
bos@559
|
517
|
|
bos@559
|
518 <para>A hook that executes successfully must exit with a status
|
|
bos@559
|
519 of zero if external, or return boolean <quote>false</quote> if
|
|
bos@559
|
520 in-process. Failure is indicated with a non-zero exit status
|
|
bos@559
|
521 from an external hook, or an in-process hook returning boolean
|
|
bos@559
|
522 <quote>true</quote>. If an in-process hook raises an
|
|
bos@559
|
523 exception, the hook is considered to have failed.
|
|
bos@559
|
524 </para>
|
|
bos@559
|
525
|
|
bos@559
|
526 <para>For a hook that controls whether an activity can proceed,
|
|
bos@559
|
527 zero/false means <quote>allow</quote>, while
|
|
bos@559
|
528 non-zero/true/exception means <quote>deny</quote>.
|
|
bos@559
|
529 </para>
|
|
bos@559
|
530
|
|
bos@559
|
531 </sect2>
|
|
bos@559
|
532 <sect2>
|
|
bos@559
|
533 <title>Writing an external hook</title>
|
|
bos@559
|
534
|
|
bos@559
|
535 <para>When you define an external hook in your <filename
|
|
bos@559
|
536 role="special"> /.hgrc</filename>\ and the hook is run, its
|
|
bos@559
|
537 value is passed to your shell, which interprets it. This
|
|
bos@559
|
538 means that you can use normal shell constructs in the body of
|
|
bos@559
|
539 the hook.
|
|
bos@559
|
540 </para>
|
|
bos@559
|
541
|
|
bos@559
|
542 <para>An executable hook is always run with its current
|
|
bos@559
|
543 directory set to a repository's root directory.
|
|
bos@559
|
544 </para>
|
|
bos@559
|
545
|
|
bos@559
|
546 <para>Each hook parameter is passed in as an environment
|
|
bos@559
|
547 variable; the name is upper-cased, and prefixed with the
|
|
bos@559
|
548 string <quote><literal>HG_</literal></quote>.
|
|
bos@559
|
549 </para>
|
|
bos@559
|
550
|
|
bos@559
|
551 <para>With the exception of hook parameters, Mercurial does not
|
|
bos@559
|
552 set or modify any environment variables when running a hook.
|
|
bos@559
|
553 This is useful to remember if you are writing a site-wide hook
|
|
bos@559
|
554 that may be run by a number of different users with differing
|
|
bos@559
|
555 environment variables set. In multi-user situations, you
|
|
bos@559
|
556 should not rely on environment variables being set to the
|
|
bos@559
|
557 values you have in your environment when testing the hook.
|
|
bos@559
|
558 </para>
|
|
bos@559
|
559
|
|
bos@559
|
560 </sect2>
|
|
bos@559
|
561 <sect2>
|
|
bos@559
|
562 <title>Telling Mercurial to use an in-process hook</title>
|
|
bos@559
|
563
|
|
bos@559
|
564 <para>The <filename role="special"> /.hgrc</filename>\ syntax
|
|
bos@559
|
565 for defining an in-process hook is slightly different than for
|
|
bos@559
|
566 an executable hook. The value of the hook must start with the
|
|
bos@559
|
567 text <quote><literal>python:</literal></quote>, and continue
|
|
bos@559
|
568 with the fully-qualified name of a callable object to use as
|
|
bos@559
|
569 the hook's value.
|
|
bos@559
|
570 </para>
|
|
bos@559
|
571
|
|
bos@559
|
572 <para>The module in which a hook lives is automatically imported
|
|
bos@559
|
573 when a hook is run. So long as you have the module name and
|
|
bos@559
|
574 <envar>PYTHONPATH</envar> right, it should <quote>just
|
|
bos@559
|
575 work</quote>.
|
|
bos@559
|
576 </para>
|
|
bos@559
|
577
|
|
bos@559
|
578 <para>The following <filename role="special"> /.hgrc</filename>\
|
|
bos@559
|
579 example snippet illustrates the syntax and meaning of the
|
|
bos@559
|
580 notions we just described.
|
|
bos@559
|
581 </para>
|
|
bos@559
|
582 <programlisting>[hooks] commit.example =
|
|
bos@559
|
583 python:mymodule.submodule.myhook</programlisting>
|
|
bos@559
|
584 <para>When Mercurial runs the <literal>commit.example</literal>
|
|
bos@559
|
585 hook, it imports <literal>mymodule.submodule</literal>, looks
|
|
bos@559
|
586 for the callable object named <literal>myhook</literal>, and
|
|
bos@559
|
587 calls it.
|
|
bos@559
|
588 </para>
|
|
bos@559
|
589
|
|
bos@559
|
590 </sect2>
|
|
bos@559
|
591 <sect2>
|
|
bos@559
|
592 <title>Writing an in-process hook</title>
|
|
bos@559
|
593
|
|
bos@559
|
594 <para>The simplest in-process hook does nothing, but illustrates
|
|
bos@559
|
595 the basic shape of the hook API:
|
|
bos@559
|
596 </para>
|
|
bos@559
|
597 <programlisting>def myhook(ui, repo, **kwargs):
|
|
bos@559
|
598 pass</programlisting>
|
|
bos@559
|
599 <para>The first argument to a Python hook is always a <literal
|
|
bos@559
|
600 role="py-mod-mercurial.ui">ui</literal> object. The second
|
|
bos@559
|
601 is a repository object; at the moment, it is always an
|
|
bos@559
|
602 instance of <literal
|
|
bos@559
|
603 role="py-mod-mercurial.localrepo">localrepository</literal>.
|
|
bos@559
|
604 Following these two arguments are other keyword arguments.
|
|
bos@559
|
605 Which ones are passed in depends on the hook being called, but
|
|
bos@559
|
606 a hook can ignore arguments it doesn't care about by dropping
|
|
bos@559
|
607 them into a keyword argument dict, as with
|
|
bos@559
|
608 <literal>**kwargs</literal> above.
|
|
bos@559
|
609 </para>
|
|
bos@559
|
610
|
|
bos@559
|
611 </sect2>
|
|
bos@559
|
612 </sect1>
|
|
bos@559
|
613 <sect1>
|
|
bos@559
|
614 <title>Some hook examples</title>
|
|
bos@559
|
615
|
|
bos@559
|
616 <sect2>
|
|
bos@559
|
617 <title>Writing meaningful commit messages</title>
|
|
bos@559
|
618
|
|
bos@559
|
619 <para>It's hard to imagine a useful commit message being very
|
|
bos@559
|
620 short. The simple <literal role="hook">pretxncommit</literal>
|
|
bos@559
|
621 hook of the example below will prevent you from committing a
|
|
bos@559
|
622 changeset with a message that is less than ten bytes long.
|
|
bos@559
|
623 </para>
|
|
bos@559
|
624
|
|
bos@567
|
625 &interaction.hook.msglen.go;
|
|
bos@559
|
626
|
|
bos@559
|
627 </sect2>
|
|
bos@559
|
628 <sect2>
|
|
bos@559
|
629 <title>Checking for trailing whitespace</title>
|
|
bos@559
|
630
|
|
bos@559
|
631 <para>An interesting use of a commit-related hook is to help you
|
|
bos@559
|
632 to write cleaner code. A simple example of <quote>cleaner
|
|
bos@559
|
633 code</quote> is the dictum that a change should not add any
|
|
bos@559
|
634 new lines of text that contain <quote>trailing
|
|
bos@559
|
635 whitespace</quote>. Trailing whitespace is a series of
|
|
bos@559
|
636 space and tab characters at the end of a line of text. In
|
|
bos@559
|
637 most cases, trailing whitespace is unnecessary, invisible
|
|
bos@559
|
638 noise, but it is occasionally problematic, and people often
|
|
bos@559
|
639 prefer to get rid of it.
|
|
bos@559
|
640 </para>
|
|
bos@559
|
641
|
|
bos@559
|
642 <para>You can use either the <literal
|
|
bos@559
|
643 role="hook">precommit</literal> or <literal
|
|
bos@559
|
644 role="hook">pretxncommit</literal> hook to tell whether you
|
|
bos@559
|
645 have a trailing whitespace problem. If you use the <literal
|
|
bos@559
|
646 role="hook">precommit</literal> hook, the hook will not know
|
|
bos@559
|
647 which files you are committing, so it will have to check every
|
|
bos@559
|
648 modified file in the repository for trailing white space. If
|
|
bos@559
|
649 you want to commit a change to just the file
|
|
bos@559
|
650 <filename>foo</filename>, but the file
|
|
bos@559
|
651 <filename>bar</filename> contains trailing whitespace, doing a
|
|
bos@559
|
652 check in the <literal role="hook">precommit</literal> hook
|
|
bos@559
|
653 will prevent you from committing <filename>foo</filename> due
|
|
bos@559
|
654 to the problem with <filename>bar</filename>. This doesn't
|
|
bos@559
|
655 seem right.
|
|
bos@559
|
656 </para>
|
|
bos@559
|
657
|
|
bos@559
|
658 <para>Should you choose the <literal
|
|
bos@559
|
659 role="hook">pretxncommit</literal> hook, the check won't
|
|
bos@559
|
660 occur until just before the transaction for the commit
|
|
bos@559
|
661 completes. This will allow you to check for problems only the
|
|
bos@559
|
662 exact files that are being committed. However, if you entered
|
|
bos@559
|
663 the commit message interactively and the hook fails, the
|
|
bos@559
|
664 transaction will roll back; you'll have to re-enter the commit
|
|
bos@559
|
665 message after you fix the trailing whitespace and run <command
|
|
bos@559
|
666 role="hg-cmd">hg commit</command> again.
|
|
bos@559
|
667 </para>
|
|
bos@559
|
668
|
|
bos@567
|
669 &interaction.hook.ws.simple;
|
|
bos@559
|
670
|
|
bos@559
|
671 <para>In this example, we introduce a simple <literal
|
|
bos@559
|
672 role="hook">pretxncommit</literal> hook that checks for
|
|
bos@559
|
673 trailing whitespace. This hook is short, but not very
|
|
bos@559
|
674 helpful. It exits with an error status if a change adds a
|
|
bos@559
|
675 line with trailing whitespace to any file, but does not print
|
|
bos@559
|
676 any information that might help us to identify the offending
|
|
bos@559
|
677 file or line. It also has the nice property of not paying
|
|
bos@559
|
678 attention to unmodified lines; only lines that introduce new
|
|
bos@559
|
679 trailing whitespace cause problems.
|
|
bos@559
|
680 </para>
|
|
bos@559
|
681
|
|
bos@559
|
682 <para>The above version is much more complex, but also more
|
|
bos@559
|
683 useful. It parses a unified diff to see if any lines add
|
|
bos@559
|
684 trailing whitespace, and prints the name of the file and the
|
|
bos@559
|
685 line number of each such occurrence. Even better, if the
|
|
bos@559
|
686 change adds trailing whitespace, this hook saves the commit
|
|
bos@559
|
687 comment and prints the name of the save file before exiting
|
|
bos@559
|
688 and telling Mercurial to roll the transaction back, so you can
|
|
bos@559
|
689 use the <option role="hg-opt-commit">-l filename</option>
|
|
bos@559
|
690 option to <command role="hg-cmd">hg commit</command> to reuse
|
|
bos@559
|
691 the saved commit message once you've corrected the problem.
|
|
bos@559
|
692 </para>
|
|
bos@559
|
693
|
|
bos@567
|
694 &interaction.hook.ws.better;
|
|
bos@559
|
695
|
|
bos@559
|
696 <para>As a final aside, note in the example above the use of
|
|
bos@559
|
697 <command>perl</command>'s in-place editing feature to get rid
|
|
bos@559
|
698 of trailing whitespace from a file. This is concise and
|
|
bos@559
|
699 useful enough that I will reproduce it here.
|
|
bos@559
|
700 </para>
|
|
bos@559
|
701 <programlisting>perl -pi -e 's,\s+$,,' filename</programlisting>
|
|
bos@559
|
702
|
|
bos@559
|
703 </sect2>
|
|
bos@559
|
704 </sect1>
|
|
bos@559
|
705 <sect1>
|
|
bos@559
|
706 <title>Bundled hooks</title>
|
|
bos@559
|
707
|
|
bos@559
|
708 <para>Mercurial ships with several bundled hooks. You can find
|
|
bos@559
|
709 them in the <filename class="directory">hgext</filename>
|
|
bos@559
|
710 directory of a Mercurial source tree. If you are using a
|
|
bos@559
|
711 Mercurial binary package, the hooks will be located in the
|
|
bos@559
|
712 <filename class="directory">hgext</filename> directory of
|
|
bos@559
|
713 wherever your package installer put Mercurial.
|
|
bos@559
|
714 </para>
|
|
bos@559
|
715
|
|
bos@559
|
716 <sect2>
|
|
bos@559
|
717 <title><literal role="hg-ext">acl</literal>&emdash;access
|
|
bos@559
|
718 control for parts of a repository</title>
|
|
bos@559
|
719
|
|
bos@559
|
720 <para>The <literal role="hg-ext">acl</literal> extension lets
|
|
bos@559
|
721 you control which remote users are allowed to push changesets
|
|
bos@559
|
722 to a networked server. You can protect any portion of a
|
|
bos@559
|
723 repository (including the entire repo), so that a specific
|
|
bos@559
|
724 remote user can push changes that do not affect the protected
|
|
bos@559
|
725 portion.
|
|
bos@559
|
726 </para>
|
|
bos@559
|
727
|
|
bos@559
|
728 <para>This extension implements access control based on the
|
|
bos@559
|
729 identity of the user performing a push,
|
|
bos@559
|
730 <emphasis>not</emphasis> on who committed the changesets
|
|
bos@559
|
731 they're pushing. It makes sense to use this hook only if you
|
|
bos@559
|
732 have a locked-down server environment that authenticates
|
|
bos@559
|
733 remote users, and you want to be sure that only specific users
|
|
bos@559
|
734 are allowed to push changes to that server.
|
|
bos@559
|
735 </para>
|
|
bos@559
|
736
|
|
bos@559
|
737 <sect3>
|
|
bos@559
|
738 <title>Configuring the <literal role="hook">acl</literal>
|
|
bos@559
|
739 hook</title>
|
|
bos@559
|
740
|
|
bos@559
|
741 <para>In order to manage incoming changesets, the <literal
|
|
bos@559
|
742 role="hg-ext">acl</literal> hook must be used as a
|
|
bos@559
|
743 <literal role="hook">pretxnchangegroup</literal> hook. This
|
|
bos@559
|
744 lets it see which files are modified by each incoming
|
|
bos@559
|
745 changeset, and roll back a group of changesets if they
|
|
bos@559
|
746 modify <quote>forbidden</quote> files. Example:
|
|
bos@559
|
747 </para>
|
|
bos@559
|
748 <programlisting>[hooks] pretxnchangegroup.acl =
|
|
bos@559
|
749 python:hgext.acl.hook</programlisting>
|
|
bos@559
|
750
|
|
bos@559
|
751 <para>The <literal role="hg-ext">acl</literal> extension is
|
|
bos@559
|
752 configured using three sections.
|
|
bos@559
|
753 </para>
|
|
bos@559
|
754
|
|
bos@559
|
755 <para>The <literal role="rc-acl">acl</literal> section has
|
|
bos@559
|
756 only one entry, <envar role="rc-item-acl">sources</envar>,
|
|
bos@559
|
757 which lists the sources of incoming changesets that the hook
|
|
bos@559
|
758 should pay attention to. You don't normally need to
|
|
bos@559
|
759 configure this section.
|
|
bos@559
|
760 </para>
|
|
bos@559
|
761 <itemizedlist>
|
|
bos@559
|
762 <listitem><para><envar role="rc-item-acl">serve</envar>:
|
|
bos@559
|
763 Control incoming changesets that are arriving from a
|
|
bos@559
|
764 remote repository over http or ssh. This is the default
|
|
bos@559
|
765 value of <envar role="rc-item-acl">sources</envar>, and
|
|
bos@559
|
766 usually the only setting you'll need for this
|
|
bos@559
|
767 configuration item.
|
|
bos@559
|
768 </para>
|
|
bos@559
|
769 </listitem>
|
|
bos@559
|
770 <listitem><para><envar role="rc-item-acl">pull</envar>:
|
|
bos@559
|
771 Control incoming changesets that are arriving via a pull
|
|
bos@559
|
772 from a local repository.
|
|
bos@559
|
773 </para>
|
|
bos@559
|
774 </listitem>
|
|
bos@559
|
775 <listitem><para><envar role="rc-item-acl">push</envar>:
|
|
bos@559
|
776 Control incoming changesets that are arriving via a push
|
|
bos@559
|
777 from a local repository.
|
|
bos@559
|
778 </para>
|
|
bos@559
|
779 </listitem>
|
|
bos@559
|
780 <listitem><para><envar role="rc-item-acl">bundle</envar>:
|
|
bos@559
|
781 Control incoming changesets that are arriving from
|
|
bos@559
|
782 another repository via a bundle.
|
|
bos@559
|
783 </para>
|
|
bos@559
|
784 </listitem></itemizedlist>
|
|
bos@559
|
785
|
|
bos@559
|
786 <para>The <literal role="rc-acl.allow">acl.allow</literal>
|
|
bos@559
|
787 section controls the users that are allowed to add
|
|
bos@559
|
788 changesets to the repository. If this section is not
|
|
bos@559
|
789 present, all users that are not explicitly denied are
|
|
bos@559
|
790 allowed. If this section is present, all users that are not
|
|
bos@559
|
791 explicitly allowed are denied (so an empty section means
|
|
bos@559
|
792 that all users are denied).
|
|
bos@559
|
793 </para>
|
|
bos@559
|
794
|
|
bos@559
|
795 <para>The <literal role="rc-acl.deny">acl.deny</literal>
|
|
bos@559
|
796 section determines which users are denied from adding
|
|
bos@559
|
797 changesets to the repository. If this section is not
|
|
bos@559
|
798 present or is empty, no users are denied.
|
|
bos@559
|
799 </para>
|
|
bos@559
|
800
|
|
bos@559
|
801 <para>The syntaxes for the <literal
|
|
bos@559
|
802 role="rc-acl.allow">acl.allow</literal> and <literal
|
|
bos@559
|
803 role="rc-acl.deny">acl.deny</literal> sections are
|
|
bos@559
|
804 identical. On the left of each entry is a glob pattern that
|
|
bos@559
|
805 matches files or directories, relative to the root of the
|
|
bos@559
|
806 repository; on the right, a user name.
|
|
bos@559
|
807 </para>
|
|
bos@559
|
808
|
|
bos@559
|
809 <para>In the following example, the user
|
|
bos@559
|
810 <literal>docwriter</literal> can only push changes to the
|
|
bos@559
|
811 <filename class="directory">docs</filename> subtree of the
|
|
bos@559
|
812 repository, while <literal>intern</literal> can push changes
|
|
bos@559
|
813 to any file or directory except <filename
|
|
bos@559
|
814 class="directory">source/sensitive</filename>.
|
|
bos@559
|
815 </para>
|
|
bos@559
|
816 <programlisting>[acl.allow] docs/** = docwriter [acl.deny]
|
|
bos@559
|
817 source/sensitive/** = intern</programlisting>
|
|
bos@559
|
818
|
|
bos@559
|
819 </sect3>
|
|
bos@559
|
820 <sect3>
|
|
bos@559
|
821 <title>Testing and troubleshooting</title>
|
|
bos@559
|
822
|
|
bos@559
|
823 <para>If you want to test the <literal
|
|
bos@559
|
824 role="hg-ext">acl</literal> hook, run it with Mercurial's
|
|
bos@559
|
825 debugging output enabled. Since you'll probably be running
|
|
bos@559
|
826 it on a server where it's not convenient (or sometimes
|
|
bos@559
|
827 possible) to pass in the <option
|
|
bos@559
|
828 role="hg-opt-global">--debug</option> option, don't forget
|
|
bos@559
|
829 that you can enable debugging output in your <filename
|
|
bos@559
|
830 role="special"> /.hgrc</filename>:
|
|
bos@559
|
831 </para>
|
|
bos@559
|
832 <programlisting>[ui] debug = true</programlisting>
|
|
bos@559
|
833 <para>With this enabled, the <literal
|
|
bos@559
|
834 role="hg-ext">acl</literal> hook will print enough
|
|
bos@559
|
835 information to let you figure out why it is allowing or
|
|
bos@559
|
836 forbidding pushes from specific users.
|
|
bos@559
|
837 </para>
|
|
bos@559
|
838
|
|
bos@559
|
839 </sect3>
|
|
bos@559
|
840 </sect2>
|
|
bos@559
|
841 <sect2>
|
|
bos@559
|
842 <title><literal
|
|
bos@559
|
843 role="hg-ext">bugzilla</literal>&emdash;integration with
|
|
bos@559
|
844 Bugzilla</title>
|
|
bos@559
|
845
|
|
bos@559
|
846 <para>The <literal role="hg-ext">bugzilla</literal> extension
|
|
bos@559
|
847 adds a comment to a Bugzilla bug whenever it finds a reference
|
|
bos@559
|
848 to that bug ID in a commit comment. You can install this hook
|
|
bos@559
|
849 on a shared server, so that any time a remote user pushes
|
|
bos@559
|
850 changes to this server, the hook gets run.
|
|
bos@559
|
851 </para>
|
|
bos@559
|
852
|
|
bos@559
|
853 <para>It adds a comment to the bug that looks like this (you can
|
|
bos@559
|
854 configure the contents of the comment&emdash;see below):
|
|
bos@559
|
855 </para>
|
|
bos@559
|
856 <programlisting>Changeset aad8b264143a, made by Joe User
|
|
bos@559
|
857 <joe.user@domain.com> in the frobnitz repository, refers
|
|
bos@559
|
858 to this bug. For complete details, see
|
|
bos@559
|
859 http://hg.domain.com/frobnitz?cmd=changeset;node=aad8b264143a
|
|
bos@559
|
860 Changeset description: Fix bug 10483 by guarding against some
|
|
bos@559
|
861 NULL pointers</programlisting>
|
|
bos@559
|
862 <para>The value of this hook is that it automates the process of
|
|
bos@559
|
863 updating a bug any time a changeset refers to it. If you
|
|
bos@559
|
864 configure the hook properly, it makes it easy for people to
|
|
bos@559
|
865 browse straight from a Bugzilla bug to a changeset that refers
|
|
bos@559
|
866 to that bug.
|
|
bos@559
|
867 </para>
|
|
bos@559
|
868
|
|
bos@559
|
869 <para>You can use the code in this hook as a starting point for
|
|
bos@559
|
870 some more exotic Bugzilla integration recipes. Here are a few
|
|
bos@559
|
871 possibilities:
|
|
bos@559
|
872 </para>
|
|
bos@559
|
873 <itemizedlist>
|
|
bos@559
|
874 <listitem><para>Require that every changeset pushed to the
|
|
bos@559
|
875 server have a valid bug ID in its commit comment. In this
|
|
bos@559
|
876 case, you'd want to configure the hook as a <literal
|
|
bos@559
|
877 role="hook">pretxncommit</literal> hook. This would
|
|
bos@559
|
878 allow the hook to reject changes that didn't contain bug
|
|
bos@559
|
879 IDs.
|
|
bos@559
|
880 </para>
|
|
bos@559
|
881 </listitem>
|
|
bos@559
|
882 <listitem><para>Allow incoming changesets to automatically
|
|
bos@559
|
883 modify the <emphasis>state</emphasis> of a bug, as well as
|
|
bos@559
|
884 simply adding a comment. For example, the hook could
|
|
bos@559
|
885 recognise the string <quote>fixed bug 31337</quote> as
|
|
bos@559
|
886 indicating that it should update the state of bug 31337 to
|
|
bos@559
|
887 <quote>requires testing</quote>.
|
|
bos@559
|
888 </para>
|
|
bos@559
|
889 </listitem></itemizedlist>
|
|
bos@559
|
890
|
|
bos@559
|
891 <sect3 id="sec:hook:bugzilla:config">
|
|
bos@559
|
892 <title>Configuring the <literal role="hook">bugzilla</literal>
|
|
bos@559
|
893 hook</title>
|
|
bos@559
|
894
|
|
bos@559
|
895 <para>You should configure this hook in your server's
|
|
bos@559
|
896 <filename role="special"> /.hgrc</filename>\ as an <literal
|
|
bos@559
|
897 role="hook">incoming</literal> hook, for example as
|
|
bos@559
|
898 follows:
|
|
bos@559
|
899 </para>
|
|
bos@559
|
900 <programlisting>[hooks] incoming.bugzilla =
|
|
bos@559
|
901 python:hgext.bugzilla.hook</programlisting>
|
|
bos@559
|
902
|
|
bos@559
|
903 <para>Because of the specialised nature of this hook, and
|
|
bos@559
|
904 because Bugzilla was not written with this kind of
|
|
bos@559
|
905 integration in mind, configuring this hook is a somewhat
|
|
bos@559
|
906 involved process.
|
|
bos@559
|
907 </para>
|
|
bos@559
|
908
|
|
bos@559
|
909 <para>Before you begin, you must install the MySQL bindings
|
|
bos@559
|
910 for Python on the host(s) where you'll be running the hook.
|
|
bos@559
|
911 If this is not available as a binary package for your
|
|
bos@559
|
912 system, you can download it from
|
|
bos@559
|
913 <citation>web:mysql-python</citation>.
|
|
bos@559
|
914 </para>
|
|
bos@559
|
915
|
|
bos@559
|
916 <para>Configuration information for this hook lives in the
|
|
bos@559
|
917 <literal role="rc-bugzilla">bugzilla</literal> section of
|
|
bos@559
|
918 your <filename role="special"> /.hgrc</filename>.
|
|
bos@559
|
919 </para>
|
|
bos@559
|
920 <itemizedlist>
|
|
bos@559
|
921 <listitem><para><envar
|
|
bos@559
|
922 role="rc-item-bugzilla">version</envar>: The version
|
|
bos@559
|
923 of Bugzilla installed on the server. The database
|
|
bos@559
|
924 schema that Bugzilla uses changes occasionally, so this
|
|
bos@559
|
925 hook has to know exactly which schema to use. At the
|
|
bos@559
|
926 moment, the only version supported is
|
|
bos@559
|
927 <literal>2.16</literal>.
|
|
bos@559
|
928 </para>
|
|
bos@559
|
929 </listitem>
|
|
bos@559
|
930 <listitem><para><envar role="rc-item-bugzilla">host</envar>:
|
|
bos@559
|
931 The hostname of the MySQL server that stores your
|
|
bos@559
|
932 Bugzilla data. The database must be configured to allow
|
|
bos@559
|
933 connections from whatever host you are running the
|
|
bos@559
|
934 <literal role="hook">bugzilla</literal> hook on.
|
|
bos@559
|
935 </para>
|
|
bos@559
|
936 </listitem>
|
|
bos@559
|
937 <listitem><para><envar role="rc-item-bugzilla">user</envar>:
|
|
bos@559
|
938 The username with which to connect to the MySQL server.
|
|
bos@559
|
939 The database must be configured to allow this user to
|
|
bos@559
|
940 connect from whatever host you are running the <literal
|
|
bos@559
|
941 role="hook">bugzilla</literal> hook on. This user
|
|
bos@559
|
942 must be able to access and modify Bugzilla tables. The
|
|
bos@559
|
943 default value of this item is <literal>bugs</literal>,
|
|
bos@559
|
944 which is the standard name of the Bugzilla user in a
|
|
bos@559
|
945 MySQL database.
|
|
bos@559
|
946 </para>
|
|
bos@559
|
947 </listitem>
|
|
bos@559
|
948 <listitem><para><envar
|
|
bos@559
|
949 role="rc-item-bugzilla">password</envar>: The MySQL
|
|
bos@559
|
950 password for the user you configured above. This is
|
|
bos@559
|
951 stored as plain text, so you should make sure that
|
|
bos@559
|
952 unauthorised users cannot read the <filename
|
|
bos@559
|
953 role="special"> /.hgrc</filename>\ file where you
|
|
bos@559
|
954 store this information.
|
|
bos@559
|
955 </para>
|
|
bos@559
|
956 </listitem>
|
|
bos@559
|
957 <listitem><para><envar role="rc-item-bugzilla">db</envar>:
|
|
bos@559
|
958 The name of the Bugzilla database on the MySQL server.
|
|
bos@559
|
959 The default value of this item is
|
|
bos@559
|
960 <literal>bugs</literal>, which is the standard name of
|
|
bos@559
|
961 the MySQL database where Bugzilla stores its data.
|
|
bos@559
|
962 </para>
|
|
bos@559
|
963 </listitem>
|
|
bos@559
|
964 <listitem><para><envar
|
|
bos@559
|
965 role="rc-item-bugzilla">notify</envar>: If you want
|
|
bos@559
|
966 Bugzilla to send out a notification email to subscribers
|
|
bos@559
|
967 after this hook has added a comment to a bug, you will
|
|
bos@559
|
968 need this hook to run a command whenever it updates the
|
|
bos@559
|
969 database. The command to run depends on where you have
|
|
bos@559
|
970 installed Bugzilla, but it will typically look something
|
|
bos@559
|
971 like this, if you have Bugzilla installed in <filename
|
|
bos@559
|
972 class="directory">/var/www/html/bugzilla</filename>:
|
|
bos@559
|
973 </para>
|
|
bos@559
|
974 <programlisting>cd /var/www/html/bugzilla &&
|
|
bos@559
|
975 ./processmail %s nobody@nowhere.com</programlisting>
|
|
bos@559
|
976 </listitem>
|
|
bos@559
|
977 <listitem><para> The Bugzilla
|
|
bos@559
|
978 <literal>processmail</literal> program expects to be
|
|
bos@559
|
979 given a bug ID (the hook replaces
|
|
bos@559
|
980 <quote><literal>%s</literal></quote> with the bug ID)
|
|
bos@559
|
981 and an email address. It also expects to be able to
|
|
bos@559
|
982 write to some files in the directory that it runs in.
|
|
bos@559
|
983 If Bugzilla and this hook are not installed on the same
|
|
bos@559
|
984 machine, you will need to find a way to run
|
|
bos@559
|
985 <literal>processmail</literal> on the server where
|
|
bos@559
|
986 Bugzilla is installed.
|
|
bos@559
|
987 </para>
|
|
bos@559
|
988 </listitem></itemizedlist>
|
|
bos@559
|
989
|
|
bos@559
|
990 </sect3>
|
|
bos@559
|
991 <sect3>
|
|
bos@559
|
992 <title>Mapping committer names to Bugzilla user names</title>
|
|
bos@559
|
993
|
|
bos@559
|
994 <para>By default, the <literal
|
|
bos@559
|
995 role="hg-ext">bugzilla</literal> hook tries to use the
|
|
bos@559
|
996 email address of a changeset's committer as the Bugzilla
|
|
bos@559
|
997 user name with which to update a bug. If this does not suit
|
|
bos@559
|
998 your needs, you can map committer email addresses to
|
|
bos@559
|
999 Bugzilla user names using a <literal
|
|
bos@559
|
1000 role="rc-usermap">usermap</literal> section.
|
|
bos@559
|
1001 </para>
|
|
bos@559
|
1002
|
|
bos@559
|
1003 <para>Each item in the <literal
|
|
bos@559
|
1004 role="rc-usermap">usermap</literal> section contains an
|
|
bos@559
|
1005 email address on the left, and a Bugzilla user name on the
|
|
bos@559
|
1006 right.
|
|
bos@559
|
1007 </para>
|
|
bos@559
|
1008 <programlisting>[usermap] jane.user@example.com =
|
|
bos@559
|
1009 jane</programlisting>
|
|
bos@559
|
1010 <para>You can either keep the <literal
|
|
bos@559
|
1011 role="rc-usermap">usermap</literal> data in a normal
|
|
bos@559
|
1012 <filename role="special">~/.hgrc</filename>, or tell the
|
|
bos@559
|
1013 <literal role="hg-ext">bugzilla</literal> hook to read the
|
|
bos@559
|
1014 information from an external <filename>usermap</filename>
|
|
bos@559
|
1015 file. In the latter case, you can store
|
|
bos@559
|
1016 <filename>usermap</filename> data by itself in (for example)
|
|
bos@559
|
1017 a user-modifiable repository. This makes it possible to let
|
|
bos@559
|
1018 your users maintain their own <envar
|
|
bos@559
|
1019 role="rc-item-bugzilla">usermap</envar> entries. The main
|
|
bos@559
|
1020 <filename role="special"> /.hgrc</filename>\ file might look
|
|
bos@559
|
1021 like this:
|
|
bos@559
|
1022 </para>
|
|
bos@559
|
1023 <programlisting># regular hgrc file refers to external usermap
|
|
bos@559
|
1024 file [bugzilla] usermap =
|
|
bos@559
|
1025 /home/hg/repos/userdata/bugzilla-usermap.conf</programlisting>
|
|
bos@559
|
1026 <para>While the <filename>usermap</filename> file that it
|
|
bos@559
|
1027 refers to might look like this:
|
|
bos@559
|
1028 </para>
|
|
bos@559
|
1029 <programlisting># bugzilla-usermap.conf - inside a hg
|
|
bos@559
|
1030 repository [usermap] stephanie@example.com =
|
|
bos@559
|
1031 steph</programlisting>
|
|
bos@559
|
1032
|
|
bos@559
|
1033 </sect3>
|
|
bos@559
|
1034 <sect3>
|
|
bos@559
|
1035 <title>Configuring the text that gets added to a bug</title>
|
|
bos@559
|
1036
|
|
bos@559
|
1037 <para>You can configure the text that this hook adds as a
|
|
bos@559
|
1038 comment; you specify it in the form of a Mercurial template.
|
|
bos@559
|
1039 Several <filename role="special"> /.hgrc</filename>\ entries
|
|
bos@559
|
1040 (still in the <literal role="rc-bugzilla">bugzilla</literal>
|
|
bos@559
|
1041 section) control this behaviour.
|
|
bos@559
|
1042 </para>
|
|
bos@559
|
1043 <itemizedlist>
|
|
bos@559
|
1044 <listitem><para><literal>strip</literal>: The number of
|
|
bos@559
|
1045 leading path elements to strip from a repository's path
|
|
bos@559
|
1046 name to construct a partial path for a URL. For example,
|
|
bos@559
|
1047 if the repositories on your server live under <filename
|
|
bos@559
|
1048 class="directory">/home/hg/repos</filename>, and you
|
|
bos@559
|
1049 have a repository whose path is <filename
|
|
bos@559
|
1050 class="directory">/home/hg/repos/app/tests</filename>,
|
|
bos@559
|
1051 then setting <literal>strip</literal> to
|
|
bos@559
|
1052 <literal>4</literal> will give a partial path of
|
|
bos@559
|
1053 <filename class="directory">app/tests</filename>. The
|
|
bos@559
|
1054 hook will make this partial path available when
|
|
bos@559
|
1055 expanding a template, as <literal>webroot</literal>.
|
|
bos@559
|
1056 </para>
|
|
bos@559
|
1057 </listitem>
|
|
bos@559
|
1058 <listitem><para><literal>template</literal>: The text of the
|
|
bos@559
|
1059 template to use. In addition to the usual
|
|
bos@559
|
1060 changeset-related variables, this template can use
|
|
bos@559
|
1061 <literal>hgweb</literal> (the value of the
|
|
bos@559
|
1062 <literal>hgweb</literal> configuration item above) and
|
|
bos@559
|
1063 <literal>webroot</literal> (the path constructed using
|
|
bos@559
|
1064 <literal>strip</literal> above).
|
|
bos@559
|
1065 </para>
|
|
bos@559
|
1066 </listitem></itemizedlist>
|
|
bos@559
|
1067
|
|
bos@559
|
1068 <para>In addition, you can add a <envar
|
|
bos@559
|
1069 role="rc-item-web">baseurl</envar> item to the <literal
|
|
bos@559
|
1070 role="rc-web">web</literal> section of your <filename
|
|
bos@559
|
1071 role="special"> /.hgrc</filename>. The <literal
|
|
bos@559
|
1072 role="hg-ext">bugzilla</literal> hook will make this
|
|
bos@559
|
1073 available when expanding a template, as the base string to
|
|
bos@559
|
1074 use when constructing a URL that will let users browse from
|
|
bos@559
|
1075 a Bugzilla comment to view a changeset. Example:
|
|
bos@559
|
1076 </para>
|
|
bos@559
|
1077 <programlisting>[web] baseurl =
|
|
bos@559
|
1078 http://hg.domain.com/</programlisting>
|
|
bos@559
|
1079
|
|
bos@559
|
1080 <para>Here is an example set of <literal
|
|
bos@559
|
1081 role="hg-ext">bugzilla</literal> hook config information.
|
|
bos@559
|
1082 </para>
|
|
bos@559
|
1083 <programlisting>[bugzilla] host = bugzilla.example.com
|
|
bos@559
|
1084 password = mypassword version = 2.16 # server-side repos
|
|
bos@559
|
1085 live in /home/hg/repos, so strip 4 leading # separators
|
|
bos@559
|
1086 strip = 4 hgweb = http://hg.example.com/ usermap =
|
|
bos@559
|
1087 /home/hg/repos/notify/bugzilla.conf template = Changeset
|
|
bos@559
|
1088 {node|short}, made by {author} in the {webroot} repo, refers
|
|
bos@559
|
1089 to this bug.\\nFor complete details, see
|
|
bos@559
|
1090 {hgweb}{webroot}?cmd=changeset;node={node|short}\\nChangeset
|
|
bos@559
|
1091 description:\\n\\t{desc|tabindent}</programlisting>
|
|
bos@559
|
1092
|
|
bos@559
|
1093 </sect3>
|
|
bos@559
|
1094 <sect3>
|
|
bos@559
|
1095 <title>Testing and troubleshooting</title>
|
|
bos@559
|
1096
|
|
bos@559
|
1097 <para>The most common problems with configuring the <literal
|
|
bos@559
|
1098 role="hg-ext">bugzilla</literal> hook relate to running
|
|
bos@559
|
1099 Bugzilla's <filename>processmail</filename> script and
|
|
bos@559
|
1100 mapping committer names to user names.
|
|
bos@559
|
1101 </para>
|
|
bos@559
|
1102
|
|
bos@559
|
1103 <para>Recall from section <xref
|
|
bos@559
|
1104 linkend="sec:hook:bugzilla:config"/> above that the user
|
|
bos@559
|
1105 that runs the Mercurial process on the server is also the
|
|
bos@559
|
1106 one that will run the <filename>processmail</filename>
|
|
bos@559
|
1107 script. The <filename>processmail</filename> script
|
|
bos@559
|
1108 sometimes causes Bugzilla to write to files in its
|
|
bos@559
|
1109 configuration directory, and Bugzilla's configuration files
|
|
bos@559
|
1110 are usually owned by the user that your web server runs
|
|
bos@559
|
1111 under.
|
|
bos@559
|
1112 </para>
|
|
bos@559
|
1113
|
|
bos@559
|
1114 <para>You can cause <filename>processmail</filename> to be run
|
|
bos@559
|
1115 with the suitable user's identity using the
|
|
bos@559
|
1116 <command>sudo</command> command. Here is an example entry
|
|
bos@559
|
1117 for a <filename>sudoers</filename> file.
|
|
bos@559
|
1118 </para>
|
|
bos@559
|
1119 <programlisting>hg_user = (httpd_user) NOPASSWD:
|
|
bos@559
|
1120 /var/www/html/bugzilla/processmail-wrapper
|
|
bos@559
|
1121 %s</programlisting>
|
|
bos@559
|
1122 <para>This allows the <literal>hg_user</literal> user to run a
|
|
bos@559
|
1123 <filename>processmail-wrapper</filename> program under the
|
|
bos@559
|
1124 identity of <literal>httpd_user</literal>.
|
|
bos@559
|
1125 </para>
|
|
bos@559
|
1126
|
|
bos@559
|
1127 <para>This indirection through a wrapper script is necessary,
|
|
bos@559
|
1128 because <filename>processmail</filename> expects to be run
|
|
bos@559
|
1129 with its current directory set to wherever you installed
|
|
bos@559
|
1130 Bugzilla; you can't specify that kind of constraint in a
|
|
bos@559
|
1131 <filename>sudoers</filename> file. The contents of the
|
|
bos@559
|
1132 wrapper script are simple:
|
|
bos@559
|
1133 </para>
|
|
bos@559
|
1134 <programlisting>#!/bin/sh cd `dirname $0` &&
|
|
bos@559
|
1135 ./processmail "$1" nobody@example.com</programlisting>
|
|
bos@559
|
1136 <para>It doesn't seem to matter what email address you pass to
|
|
bos@559
|
1137 <filename>processmail</filename>.
|
|
bos@559
|
1138 </para>
|
|
bos@559
|
1139
|
|
bos@559
|
1140 <para>If your <literal role="rc-usermap">usermap</literal> is
|
|
bos@559
|
1141 not set up correctly, users will see an error message from
|
|
bos@559
|
1142 the <literal role="hg-ext">bugzilla</literal> hook when they
|
|
bos@559
|
1143 push changes to the server. The error message will look
|
|
bos@559
|
1144 like this:
|
|
bos@559
|
1145 </para>
|
|
bos@559
|
1146 <programlisting>cannot find bugzilla user id for
|
|
bos@559
|
1147 john.q.public@example.com</programlisting>
|
|
bos@559
|
1148 <para>What this means is that the committer's address,
|
|
bos@559
|
1149 <literal>john.q.public@example.com</literal>, is not a valid
|
|
bos@559
|
1150 Bugzilla user name, nor does it have an entry in your
|
|
bos@559
|
1151 <literal role="rc-usermap">usermap</literal> that maps it to
|
|
bos@559
|
1152 a valid Bugzilla user name.
|
|
bos@559
|
1153 </para>
|
|
bos@559
|
1154
|
|
bos@559
|
1155 </sect3>
|
|
bos@559
|
1156 </sect2>
|
|
bos@559
|
1157 <sect2>
|
|
bos@559
|
1158 <title><literal role="hg-ext">notify</literal>&emdash;send email
|
|
bos@559
|
1159 notifications</title>
|
|
bos@559
|
1160
|
|
bos@559
|
1161 <para>Although Mercurial's built-in web server provides RSS
|
|
bos@559
|
1162 feeds of changes in every repository, many people prefer to
|
|
bos@559
|
1163 receive change notifications via email. The <literal
|
|
bos@559
|
1164 role="hg-ext">notify</literal> hook lets you send out
|
|
bos@559
|
1165 notifications to a set of email addresses whenever changesets
|
|
bos@559
|
1166 arrive that those subscribers are interested in.
|
|
bos@559
|
1167 </para>
|
|
bos@559
|
1168
|
|
bos@559
|
1169 <para>As with the <literal role="hg-ext">bugzilla</literal>
|
|
bos@559
|
1170 hook, the <literal role="hg-ext">notify</literal> hook is
|
|
bos@559
|
1171 template-driven, so you can customise the contents of the
|
|
bos@559
|
1172 notification messages that it sends.
|
|
bos@559
|
1173 </para>
|
|
bos@559
|
1174
|
|
bos@559
|
1175 <para>By default, the <literal role="hg-ext">notify</literal>
|
|
bos@559
|
1176 hook includes a diff of every changeset that it sends out; you
|
|
bos@559
|
1177 can limit the size of the diff, or turn this feature off
|
|
bos@559
|
1178 entirely. It is useful for letting subscribers review changes
|
|
bos@559
|
1179 immediately, rather than clicking to follow a URL.
|
|
bos@559
|
1180 </para>
|
|
bos@559
|
1181
|
|
bos@559
|
1182 <sect3>
|
|
bos@559
|
1183 <title>Configuring the <literal role="hg-ext">notify</literal>
|
|
bos@559
|
1184 hook</title>
|
|
bos@559
|
1185
|
|
bos@559
|
1186 <para>You can set up the <literal
|
|
bos@559
|
1187 role="hg-ext">notify</literal> hook to send one email
|
|
bos@559
|
1188 message per incoming changeset, or one per incoming group of
|
|
bos@559
|
1189 changesets (all those that arrived in a single pull or
|
|
bos@559
|
1190 push).
|
|
bos@559
|
1191 </para>
|
|
bos@559
|
1192 <programlisting>[hooks] # send one email per group of changes
|
|
bos@559
|
1193 changegroup.notify = python:hgext.notify.hook # send one
|
|
bos@559
|
1194 email per change incoming.notify =
|
|
bos@559
|
1195 python:hgext.notify.hook</programlisting>
|
|
bos@559
|
1196
|
|
bos@559
|
1197 <para>Configuration information for this hook lives in the
|
|
bos@559
|
1198 <literal role="rc-notify">notify</literal> section of a
|
|
bos@559
|
1199 <filename role="special"> /.hgrc</filename>\ file.
|
|
bos@559
|
1200 </para>
|
|
bos@559
|
1201 <itemizedlist>
|
|
bos@559
|
1202 <listitem><para><envar role="rc-item-notify">test</envar>:
|
|
bos@559
|
1203 By default, this hook does not send out email at all;
|
|
bos@559
|
1204 instead, it prints the message that it
|
|
bos@559
|
1205 <emphasis>would</emphasis> send. Set this item to
|
|
bos@559
|
1206 <literal>false</literal> to allow email to be sent. The
|
|
bos@559
|
1207 reason that sending of email is turned off by default is
|
|
bos@559
|
1208 that it takes several tries to configure this extension
|
|
bos@559
|
1209 exactly as you would like, and it would be bad form to
|
|
bos@559
|
1210 spam subscribers with a number of <quote>broken</quote>
|
|
bos@559
|
1211 notifications while you debug your configuration.
|
|
bos@559
|
1212 </para>
|
|
bos@559
|
1213 </listitem>
|
|
bos@559
|
1214 <listitem><para><envar role="rc-item-notify">config</envar>:
|
|
bos@559
|
1215 The path to a configuration file that contains
|
|
bos@559
|
1216 subscription information. This is kept separate from
|
|
bos@559
|
1217 the main <filename role="special"> /.hgrc</filename>\ so
|
|
bos@559
|
1218 that you can maintain it in a repository of its own.
|
|
bos@559
|
1219 People can then clone that repository, update their
|
|
bos@559
|
1220 subscriptions, and push the changes back to your server.
|
|
bos@559
|
1221 </para>
|
|
bos@559
|
1222 </listitem>
|
|
bos@559
|
1223 <listitem><para><envar role="rc-item-notify">strip</envar>:
|
|
bos@559
|
1224 The number of leading path separator characters to strip
|
|
bos@559
|
1225 from a repository's path, when deciding whether a
|
|
bos@559
|
1226 repository has subscribers. For example, if the
|
|
bos@559
|
1227 repositories on your server live in <filename
|
|
bos@559
|
1228 class="directory">/home/hg/repos</filename>, and
|
|
bos@559
|
1229 <literal role="hg-ext">notify</literal> is considering a
|
|
bos@559
|
1230 repository named <filename
|
|
bos@559
|
1231 class="directory">/home/hg/repos/shared/test</filename>,
|
|
bos@559
|
1232 setting <envar role="rc-item-notify">strip</envar> to
|
|
bos@559
|
1233 <literal>4</literal> will cause <literal
|
|
bos@559
|
1234 role="hg-ext">notify</literal> to trim the path it
|
|
bos@559
|
1235 considers down to <filename
|
|
bos@559
|
1236 class="directory">shared/test</filename>, and it will
|
|
bos@559
|
1237 match subscribers against that.
|
|
bos@559
|
1238 </para>
|
|
bos@559
|
1239 </listitem>
|
|
bos@559
|
1240 <listitem><para><envar
|
|
bos@559
|
1241 role="rc-item-notify">template</envar>: The template
|
|
bos@559
|
1242 text to use when sending messages. This specifies both
|
|
bos@559
|
1243 the contents of the message header and its body.
|
|
bos@559
|
1244 </para>
|
|
bos@559
|
1245 </listitem>
|
|
bos@559
|
1246 <listitem><para><envar
|
|
bos@559
|
1247 role="rc-item-notify">maxdiff</envar>: The maximum
|
|
bos@559
|
1248 number of lines of diff data to append to the end of a
|
|
bos@559
|
1249 message. If a diff is longer than this, it is
|
|
bos@559
|
1250 truncated. By default, this is set to 300. Set this to
|
|
bos@559
|
1251 <literal>0</literal> to omit diffs from notification
|
|
bos@559
|
1252 emails.
|
|
bos@559
|
1253 </para>
|
|
bos@559
|
1254 </listitem>
|
|
bos@559
|
1255 <listitem><para><envar
|
|
bos@559
|
1256 role="rc-item-notify">sources</envar>: A list of
|
|
bos@559
|
1257 sources of changesets to consider. This lets you limit
|
|
bos@559
|
1258 <literal role="hg-ext">notify</literal> to only sending
|
|
bos@559
|
1259 out email about changes that remote users pushed into
|
|
bos@559
|
1260 this repository via a server, for example. See section
|
|
bos@559
|
1261 <xref
|
|
bos@559
|
1262 linkend="sec:hook:sources"/> for the sources you can
|
|
bos@559
|
1263 specify here.
|
|
bos@559
|
1264 </para>
|
|
bos@559
|
1265 </listitem></itemizedlist>
|
|
bos@559
|
1266
|
|
bos@559
|
1267 <para>If you set the <envar role="rc-item-web">baseurl</envar>
|
|
bos@559
|
1268 item in the <literal role="rc-web">web</literal> section,
|
|
bos@559
|
1269 you can use it in a template; it will be available as
|
|
bos@559
|
1270 <literal>webroot</literal>.
|
|
bos@559
|
1271 </para>
|
|
bos@559
|
1272
|
|
bos@559
|
1273 <para>Here is an example set of <literal
|
|
bos@559
|
1274 role="hg-ext">notify</literal> configuration information.
|
|
bos@559
|
1275 </para>
|
|
bos@559
|
1276 <programlisting>
|
|
bos@559
|
1277 [notify] # really send email test = false # subscriber data
|
|
bos@559
|
1278 lives in the notify repo config =
|
|
bos@559
|
1279 /home/hg/repos/notify/notify.conf # repos live in
|
|
bos@559
|
1280 /home/hg/repos on server, so strip 4 "/" chars strip = 4
|
|
bos@559
|
1281 template = X-Hg-Repo: {webroot} Subject: {webroot}:
|
|
bos@559
|
1282 {desc|firstline|strip} From: {author} changeset {node|short}
|
|
bos@559
|
1283 in {root} details:
|
|
bos@559
|
1284 {baseurl}{webroot}?cmd=changeset;node={node|short}
|
|
bos@559
|
1285 description: {desc|tabindent|strip} [web] baseurl =
|
|
bos@559
|
1286 http://hg.example.com/
|
|
bos@559
|
1287 </programlisting>
|
|
bos@559
|
1288
|
|
bos@559
|
1289 <para>This will produce a message that looks like the
|
|
bos@559
|
1290 following:
|
|
bos@559
|
1291 </para>
|
|
bos@559
|
1292 <programlisting>
|
|
bos@559
|
1293 X-Hg-Repo: tests/slave Subject: tests/slave: Handle error
|
|
bos@559
|
1294 case when slave has no buffers Date: Wed, 2 Aug 2006
|
|
bos@559
|
1295 15:25:46 -0700 (PDT) changeset 3cba9bfe74b5 in
|
|
bos@559
|
1296 /home/hg/repos/tests/slave details:
|
|
bos@559
|
1297 http://hg.example.com/tests/slave?cmd=changeset;node=3cba9bfe74b5
|
|
bos@559
|
1298 description: Handle error case when slave has no buffers
|
|
bos@559
|
1299 diffs (54 lines): diff -r 9d95df7cf2ad -r 3cba9bfe74b5
|
|
bos@559
|
1300 include/tests.h --- a/include/tests.h Wed Aug 02
|
|
bos@559
|
1301 15:19:52 2006 -0700 +++ b/include/tests.h Wed Aug 02
|
|
bos@559
|
1302 15:25:26 2006 -0700 @@ -212,6 +212,15 @@ static __inline__
|
|
bos@559
|
1303 void test_headers(void *h) [...snip...]
|
|
bos@559
|
1304 </programlisting>
|
|
bos@559
|
1305
|
|
bos@559
|
1306 </sect3>
|
|
bos@559
|
1307 <sect3>
|
|
bos@559
|
1308 <title>Testing and troubleshooting</title>
|
|
bos@559
|
1309
|
|
bos@559
|
1310 <para>Do not forget that by default, the <literal
|
|
ori@561
|
1311 role="hg-ext">notify</literal> extension <emphasis>will not
|
|
ori@561
|
1312 send any mail</emphasis> until you explicitly configure it to do so,
|
|
bos@559
|
1313 by setting <envar role="rc-item-notify">test</envar> to
|
|
bos@559
|
1314 <literal>false</literal>. Until you do that, it simply
|
|
bos@559
|
1315 prints the message it <emphasis>would</emphasis> send.
|
|
bos@559
|
1316 </para>
|
|
bos@559
|
1317
|
|
bos@559
|
1318 </sect3>
|
|
bos@559
|
1319 </sect2>
|
|
bos@559
|
1320 </sect1>
|
|
bos@559
|
1321 <sect1 id="sec:hook:ref">
|
|
bos@559
|
1322 <title>Information for writers of hooks</title>
|
|
bos@559
|
1323
|
|
bos@559
|
1324 <sect2>
|
|
bos@559
|
1325 <title>In-process hook execution</title>
|
|
bos@559
|
1326
|
|
bos@559
|
1327 <para>An in-process hook is called with arguments of the
|
|
bos@559
|
1328 following form:
|
|
bos@559
|
1329 </para>
|
|
bos@559
|
1330 <programlisting>
|
|
bos@559
|
1331 def myhook(ui, repo, **kwargs): pass
|
|
bos@559
|
1332 </programlisting>
|
|
bos@559
|
1333 <para>The <literal>ui</literal> parameter is a <literal
|
|
bos@559
|
1334 role="py-mod-mercurial.ui">ui</literal> object. The
|
|
bos@559
|
1335 <literal>repo</literal> parameter is a <literal
|
|
bos@559
|
1336 role="py-mod-mercurial.localrepo">localrepository</literal>
|
|
bos@559
|
1337 object. The names and values of the
|
|
bos@559
|
1338 <literal>**kwargs</literal> parameters depend on the hook
|
|
bos@559
|
1339 being invoked, with the following common features:
|
|
bos@559
|
1340 </para>
|
|
bos@559
|
1341 <itemizedlist>
|
|
bos@559
|
1342 <listitem><para>If a parameter is named
|
|
bos@559
|
1343 <literal>node</literal> or <literal>parentN</literal>, it
|
|
bos@559
|
1344 will contain a hexadecimal changeset ID. The empty string
|
|
bos@559
|
1345 is used to represent <quote>null changeset ID</quote>
|
|
bos@559
|
1346 instead of a string of zeroes.
|
|
bos@559
|
1347 </para>
|
|
bos@559
|
1348 </listitem>
|
|
bos@559
|
1349 <listitem><para>If a parameter is named
|
|
bos@559
|
1350 <literal>url</literal>, it will contain the URL of a
|
|
bos@559
|
1351 remote repository, if that can be determined.
|
|
bos@559
|
1352 </para>
|
|
bos@559
|
1353 </listitem>
|
|
bos@559
|
1354 <listitem><para>Boolean-valued parameters are represented as
|
|
bos@559
|
1355 Python <literal>bool</literal> objects.
|
|
bos@559
|
1356 </para>
|
|
bos@559
|
1357 </listitem></itemizedlist>
|
|
bos@559
|
1358
|
|
bos@559
|
1359 <para>An in-process hook is called without a change to the
|
|
bos@559
|
1360 process's working directory (unlike external hooks, which are
|
|
bos@559
|
1361 run in the root of the repository). It must not change the
|
|
bos@559
|
1362 process's working directory, or it will cause any calls it
|
|
bos@559
|
1363 makes into the Mercurial API to fail.
|
|
bos@559
|
1364 </para>
|
|
bos@559
|
1365
|
|
bos@559
|
1366 <para>If a hook returns a boolean <quote>false</quote> value, it
|
|
bos@559
|
1367 is considered to have succeeded. If it returns a boolean
|
|
bos@559
|
1368 <quote>true</quote> value or raises an exception, it is
|
|
bos@559
|
1369 considered to have failed. A useful way to think of the
|
|
bos@559
|
1370 calling convention is <quote>tell me if you fail</quote>.
|
|
bos@559
|
1371 </para>
|
|
bos@559
|
1372
|
|
bos@559
|
1373 <para>Note that changeset IDs are passed into Python hooks as
|
|
bos@559
|
1374 hexadecimal strings, not the binary hashes that Mercurial's
|
|
bos@559
|
1375 APIs normally use. To convert a hash from hex to binary, use
|
|
bos@559
|
1376 the \pymodfunc{mercurial.node}{bin} function.
|
|
bos@559
|
1377 </para>
|
|
bos@559
|
1378
|
|
bos@559
|
1379 </sect2>
|
|
bos@559
|
1380 <sect2>
|
|
bos@559
|
1381 <title>External hook execution</title>
|
|
bos@559
|
1382
|
|
bos@559
|
1383 <para>An external hook is passed to the shell of the user
|
|
bos@559
|
1384 running Mercurial. Features of that shell, such as variable
|
|
bos@559
|
1385 substitution and command redirection, are available. The hook
|
|
bos@559
|
1386 is run in the root directory of the repository (unlike
|
|
bos@559
|
1387 in-process hooks, which are run in the same directory that
|
|
bos@559
|
1388 Mercurial was run in).
|
|
bos@559
|
1389 </para>
|
|
bos@559
|
1390
|
|
bos@559
|
1391 <para>Hook parameters are passed to the hook as environment
|
|
bos@559
|
1392 variables. Each environment variable's name is converted in
|
|
bos@559
|
1393 upper case and prefixed with the string
|
|
bos@559
|
1394 <quote><literal>HG_</literal></quote>. For example, if the
|
|
bos@559
|
1395 name of a parameter is <quote><literal>node</literal></quote>,
|
|
bos@559
|
1396 the name of the environment variable representing that
|
|
bos@559
|
1397 parameter will be <quote><literal>HG_NODE</literal></quote>.
|
|
bos@559
|
1398 </para>
|
|
bos@559
|
1399
|
|
bos@559
|
1400 <para>A boolean parameter is represented as the string
|
|
bos@559
|
1401 <quote><literal>1</literal></quote> for <quote>true</quote>,
|
|
bos@559
|
1402 <quote><literal>0</literal></quote> for <quote>false</quote>.
|
|
bos@559
|
1403 If an environment variable is named <envar>HG_NODE</envar>,
|
|
bos@559
|
1404 <envar>HG_PARENT1</envar> or <envar>HG_PARENT2</envar>, it
|
|
bos@559
|
1405 contains a changeset ID represented as a hexadecimal string.
|
|
bos@559
|
1406 The empty string is used to represent <quote>null changeset
|
|
bos@559
|
1407 ID</quote> instead of a string of zeroes. If an environment
|
|
bos@559
|
1408 variable is named <envar>HG_URL</envar>, it will contain the
|
|
bos@559
|
1409 URL of a remote repository, if that can be determined.
|
|
bos@559
|
1410 </para>
|
|
bos@559
|
1411
|
|
bos@559
|
1412 <para>If a hook exits with a status of zero, it is considered to
|
|
bos@559
|
1413 have succeeded. If it exits with a non-zero status, it is
|
|
bos@559
|
1414 considered to have failed.
|
|
bos@559
|
1415 </para>
|
|
bos@559
|
1416
|
|
bos@559
|
1417 </sect2>
|
|
bos@559
|
1418 <sect2>
|
|
bos@559
|
1419 <title>Finding out where changesets come from</title>
|
|
bos@559
|
1420
|
|
bos@559
|
1421 <para>A hook that involves the transfer of changesets between a
|
|
bos@559
|
1422 local repository and another may be able to find out
|
|
bos@559
|
1423 information about the <quote>far side</quote>. Mercurial
|
|
bos@559
|
1424 knows <emphasis>how</emphasis> changes are being transferred,
|
|
bos@559
|
1425 and in many cases <emphasis>where</emphasis> they are being
|
|
bos@559
|
1426 transferred to or from.
|
|
bos@559
|
1427 </para>
|
|
bos@559
|
1428
|
|
bos@559
|
1429 <sect3 id="sec:hook:sources">
|
|
bos@559
|
1430 <title>Sources of changesets</title>
|
|
bos@559
|
1431
|
|
bos@559
|
1432 <para>Mercurial will tell a hook what means are, or were, used
|
|
bos@559
|
1433 to transfer changesets between repositories. This is
|
|
bos@559
|
1434 provided by Mercurial in a Python parameter named
|
|
bos@559
|
1435 <literal>source</literal>, or an environment variable named
|
|
bos@559
|
1436 <envar>HG_SOURCE</envar>.
|
|
bos@559
|
1437 </para>
|
|
bos@559
|
1438
|
|
bos@559
|
1439 <itemizedlist>
|
|
bos@559
|
1440 <listitem><para><literal>serve</literal>: Changesets are
|
|
bos@559
|
1441 transferred to or from a remote repository over http or
|
|
bos@559
|
1442 ssh.
|
|
bos@559
|
1443 </para>
|
|
bos@559
|
1444 </listitem>
|
|
bos@559
|
1445 <listitem><para><literal>pull</literal>: Changesets are
|
|
bos@559
|
1446 being transferred via a pull from one repository into
|
|
bos@559
|
1447 another.
|
|
bos@559
|
1448 </para>
|
|
bos@559
|
1449 </listitem>
|
|
bos@559
|
1450 <listitem><para><literal>push</literal>: Changesets are
|
|
bos@559
|
1451 being transferred via a push from one repository into
|
|
bos@559
|
1452 another.
|
|
bos@559
|
1453 </para>
|
|
bos@559
|
1454 </listitem>
|
|
bos@559
|
1455 <listitem><para><literal>bundle</literal>: Changesets are
|
|
bos@559
|
1456 being transferred to or from a bundle.
|
|
bos@559
|
1457 </para>
|
|
bos@559
|
1458 </listitem></itemizedlist>
|
|
bos@559
|
1459
|
|
bos@559
|
1460 </sect3>
|
|
bos@559
|
1461 <sect3 id="sec:hook:url">
|
|
bos@559
|
1462 <title>Where changes are going&emdash;remote repository
|
|
bos@559
|
1463 URLs</title>
|
|
bos@559
|
1464
|
|
bos@559
|
1465 <para>When possible, Mercurial will tell a hook the location
|
|
bos@559
|
1466 of the <quote>far side</quote> of an activity that transfers
|
|
bos@559
|
1467 changeset data between repositories. This is provided by
|
|
bos@559
|
1468 Mercurial in a Python parameter named
|
|
bos@559
|
1469 <literal>url</literal>, or an environment variable named
|
|
bos@559
|
1470 <envar>HG_URL</envar>.
|
|
bos@559
|
1471 </para>
|
|
bos@559
|
1472
|
|
bos@559
|
1473 <para>This information is not always known. If a hook is
|
|
bos@559
|
1474 invoked in a repository that is being served via http or
|
|
bos@559
|
1475 ssh, Mercurial cannot tell where the remote repository is,
|
|
bos@559
|
1476 but it may know where the client is connecting from. In
|
|
bos@559
|
1477 such cases, the URL will take one of the following forms:
|
|
bos@559
|
1478 </para>
|
|
bos@559
|
1479 <itemizedlist>
|
|
bos@559
|
1480 <listitem><para><literal>remote:ssh:1.2.3.4</literal>&emdash;remote
|
|
bos@559
|
1481 ssh client, at the IP address
|
|
bos@559
|
1482 <literal>1.2.3.4</literal>.
|
|
bos@559
|
1483 </para>
|
|
bos@559
|
1484 </listitem>
|
|
bos@559
|
1485 <listitem><para><literal>remote:http:1.2.3.4</literal>&emdash;remote
|
|
bos@559
|
1486 http client, at the IP address
|
|
bos@559
|
1487 <literal>1.2.3.4</literal>. If the client is using SSL,
|
|
bos@559
|
1488 this will be of the form
|
|
bos@559
|
1489 <literal>remote:https:1.2.3.4</literal>.
|
|
bos@559
|
1490 </para>
|
|
bos@559
|
1491 </listitem>
|
|
bos@559
|
1492 <listitem><para>Empty&emdash;no information could be
|
|
bos@559
|
1493 discovered about the remote client.
|
|
bos@559
|
1494 </para>
|
|
bos@559
|
1495 </listitem></itemizedlist>
|
|
bos@559
|
1496
|
|
bos@559
|
1497 </sect3>
|
|
bos@559
|
1498 </sect2>
|
|
bos@559
|
1499 </sect1>
|
|
bos@559
|
1500 <sect1>
|
|
bos@559
|
1501 <title>Hook reference</title>
|
|
bos@559
|
1502
|
|
bos@559
|
1503 <sect2 id="sec:hook:changegroup">
|
|
bos@559
|
1504 <title><literal role="hook">changegroup</literal>&emdash;after
|
|
bos@559
|
1505 remote changesets added</title>
|
|
bos@559
|
1506
|
|
bos@559
|
1507 <para>This hook is run after a group of pre-existing changesets
|
|
bos@559
|
1508 has been added to the repository, for example via a <command
|
|
bos@559
|
1509 role="hg-cmd">hg pull</command> or <command role="hg-cmd">hg
|
|
bos@559
|
1510 unbundle</command>. This hook is run once per operation
|
|
bos@559
|
1511 that added one or more changesets. This is in contrast to the
|
|
bos@559
|
1512 <literal role="hook">incoming</literal> hook, which is run
|
|
bos@559
|
1513 once per changeset, regardless of whether the changesets
|
|
bos@559
|
1514 arrive in a group.
|
|
bos@559
|
1515 </para>
|
|
bos@559
|
1516
|
|
bos@559
|
1517 <para>Some possible uses for this hook include kicking off an
|
|
bos@559
|
1518 automated build or test of the added changesets, updating a
|
|
bos@559
|
1519 bug database, or notifying subscribers that a repository
|
|
bos@559
|
1520 contains new changes.
|
|
bos@559
|
1521 </para>
|
|
bos@559
|
1522
|
|
bos@559
|
1523 <para>Parameters to this hook:
|
|
bos@559
|
1524 </para>
|
|
bos@559
|
1525 <itemizedlist>
|
|
bos@559
|
1526 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1527 changeset ID of the first changeset in the group that was
|
|
bos@559
|
1528 added. All changesets between this and
|
|
bos@559
|
1529 \index{tags!<literal>tip</literal>}<literal>tip</literal>,
|
|
bos@559
|
1530 inclusive, were added by a single <command
|
|
bos@559
|
1531 role="hg-cmd">hg pull</command>, <command
|
|
bos@559
|
1532 role="hg-cmd">hg push</command> or <command
|
|
bos@559
|
1533 role="hg-cmd">hg unbundle</command>.
|
|
bos@559
|
1534 </para>
|
|
bos@559
|
1535 </listitem>
|
|
bos@559
|
1536 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1537 source of these changes. See section <xref
|
|
bos@559
|
1538 linkend="sec:hook:sources"/> for details.
|
|
bos@559
|
1539 </para>
|
|
bos@559
|
1540 </listitem>
|
|
bos@559
|
1541 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1542 of the remote repository, if known. See section <xref
|
|
bos@559
|
1543 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1544 information.
|
|
bos@559
|
1545 </para>
|
|
bos@559
|
1546 </listitem></itemizedlist>
|
|
bos@559
|
1547
|
|
bos@559
|
1548 <para>See also: <literal role="hook">incoming</literal> (section
|
|
bos@559
|
1549 <xref linkend="sec:hook:incoming"/>), <literal
|
|
bos@559
|
1550 role="hook">prechangegroup</literal> (section <xref
|
|
bos@559
|
1551 linkend="sec:hook:prechangegroup"/>), <literal
|
|
bos@559
|
1552 role="hook">pretxnchangegroup</literal> (section <xref
|
|
bos@559
|
1553 linkend="sec:hook:pretxnchangegroup"/>)
|
|
bos@559
|
1554 </para>
|
|
bos@559
|
1555
|
|
bos@559
|
1556 </sect2>
|
|
bos@559
|
1557 <sect2 id="sec:hook:commit">
|
|
bos@559
|
1558 <title><literal role="hook">commit</literal>&emdash;after a new
|
|
bos@559
|
1559 changeset is created</title>
|
|
bos@559
|
1560
|
|
bos@559
|
1561 <para>This hook is run after a new changeset has been created.
|
|
bos@559
|
1562 </para>
|
|
bos@559
|
1563
|
|
bos@559
|
1564 <para>Parameters to this hook:
|
|
bos@559
|
1565 </para>
|
|
bos@559
|
1566 <itemizedlist>
|
|
bos@559
|
1567 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1568 changeset ID of the newly committed changeset.
|
|
bos@559
|
1569 </para>
|
|
bos@559
|
1570 </listitem>
|
|
bos@559
|
1571 <listitem><para><literal>parent1</literal>: A changeset ID.
|
|
bos@559
|
1572 The changeset ID of the first parent of the newly
|
|
bos@559
|
1573 committed changeset.
|
|
bos@559
|
1574 </para>
|
|
bos@559
|
1575 </listitem>
|
|
bos@559
|
1576 <listitem><para><literal>parent2</literal>: A changeset ID.
|
|
bos@559
|
1577 The changeset ID of the second parent of the newly
|
|
bos@559
|
1578 committed changeset.
|
|
bos@559
|
1579 </para>
|
|
bos@559
|
1580 </listitem></itemizedlist>
|
|
bos@559
|
1581
|
|
bos@559
|
1582 <para>See also: <literal role="hook">precommit</literal>
|
|
bos@559
|
1583 (section <xref linkend="sec:hook:precommit"/>), <literal
|
|
bos@559
|
1584 role="hook">pretxncommit</literal> (section <xref
|
|
bos@559
|
1585 linkend="sec:hook:pretxncommit"/>)
|
|
bos@559
|
1586 </para>
|
|
bos@559
|
1587
|
|
bos@559
|
1588 </sect2>
|
|
bos@559
|
1589 <sect2 id="sec:hook:incoming">
|
|
bos@559
|
1590 <title><literal role="hook">incoming</literal>&emdash;after one
|
|
bos@559
|
1591 remote changeset is added</title>
|
|
bos@559
|
1592
|
|
bos@559
|
1593 <para>This hook is run after a pre-existing changeset has been
|
|
bos@559
|
1594 added to the repository, for example via a <command
|
|
bos@559
|
1595 role="hg-cmd">hg push</command>. If a group of changesets
|
|
bos@559
|
1596 was added in a single operation, this hook is called once for
|
|
bos@559
|
1597 each added changeset.
|
|
bos@559
|
1598 </para>
|
|
bos@559
|
1599
|
|
bos@559
|
1600 <para>You can use this hook for the same purposes as the
|
|
bos@559
|
1601 <literal role="hook">changegroup</literal> hook (section <xref
|
|
bos@559
|
1602 linkend="sec:hook:changegroup"/>); it's simply
|
|
bos@559
|
1603 more convenient sometimes to run a hook once per group of
|
|
bos@559
|
1604 changesets, while other times it's handier once per changeset.
|
|
bos@559
|
1605 </para>
|
|
bos@559
|
1606
|
|
bos@559
|
1607 <para>Parameters to this hook:
|
|
bos@559
|
1608 </para>
|
|
bos@559
|
1609 <itemizedlist>
|
|
bos@559
|
1610 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1611 ID of the newly added changeset.
|
|
bos@559
|
1612 </para>
|
|
bos@559
|
1613 </listitem>
|
|
bos@559
|
1614 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1615 source of these changes. See section <xref
|
|
bos@559
|
1616 linkend="sec:hook:sources"/> for details.
|
|
bos@559
|
1617 </para>
|
|
bos@559
|
1618 </listitem>
|
|
bos@559
|
1619 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1620 of the remote repository, if known. See section <xref
|
|
bos@559
|
1621 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1622 information.
|
|
bos@559
|
1623 </para>
|
|
bos@559
|
1624 </listitem></itemizedlist>
|
|
bos@559
|
1625
|
|
bos@559
|
1626 <para>See also: <literal role="hook">changegroup</literal>
|
|
bos@559
|
1627 (section <xref linkend="sec:hook:changegroup"/>) <literal
|
|
bos@559
|
1628 role="hook">prechangegroup</literal> (section <xref
|
|
bos@559
|
1629 linkend="sec:hook:prechangegroup"/>), <literal
|
|
bos@559
|
1630 role="hook">pretxnchangegroup</literal> (section <xref
|
|
bos@559
|
1631 linkend="sec:hook:pretxnchangegroup"/>)
|
|
bos@559
|
1632 </para>
|
|
bos@559
|
1633
|
|
bos@559
|
1634 </sect2>
|
|
bos@559
|
1635 <sect2 id="sec:hook:outgoing">
|
|
bos@559
|
1636 <title><literal role="hook">outgoing</literal>&emdash;after
|
|
bos@559
|
1637 changesets are propagated</title>
|
|
bos@559
|
1638
|
|
bos@559
|
1639 <para>This hook is run after a group of changesets has been
|
|
bos@559
|
1640 propagated out of this repository, for example by a <command
|
|
bos@559
|
1641 role="hg-cmd">hg push</command> or <command role="hg-cmd">hg
|
|
bos@559
|
1642 bundle</command> command.
|
|
bos@559
|
1643 </para>
|
|
bos@559
|
1644
|
|
bos@559
|
1645 <para>One possible use for this hook is to notify administrators
|
|
bos@559
|
1646 that changes have been pulled.
|
|
bos@559
|
1647 </para>
|
|
bos@559
|
1648
|
|
bos@559
|
1649 <para>Parameters to this hook:
|
|
bos@559
|
1650 </para>
|
|
bos@559
|
1651 <itemizedlist>
|
|
bos@559
|
1652 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1653 changeset ID of the first changeset of the group that was
|
|
bos@559
|
1654 sent.
|
|
bos@559
|
1655 </para>
|
|
bos@559
|
1656 </listitem>
|
|
bos@559
|
1657 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1658 source of the of the operation (see section <xref
|
|
bos@559
|
1659 linkend="sec:hook:sources"/>). If a remote
|
|
bos@559
|
1660 client pulled changes from this repository,
|
|
bos@559
|
1661 <literal>source</literal> will be
|
|
bos@559
|
1662 <literal>serve</literal>. If the client that obtained
|
|
bos@559
|
1663 changes from this repository was local,
|
|
bos@559
|
1664 <literal>source</literal> will be
|
|
bos@559
|
1665 <literal>bundle</literal>, <literal>pull</literal>, or
|
|
bos@559
|
1666 <literal>push</literal>, depending on the operation the
|
|
bos@559
|
1667 client performed.
|
|
bos@559
|
1668 </para>
|
|
bos@559
|
1669 </listitem>
|
|
bos@559
|
1670 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1671 of the remote repository, if known. See section <xref
|
|
bos@559
|
1672 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1673 information.
|
|
bos@559
|
1674 </para>
|
|
bos@559
|
1675 </listitem></itemizedlist>
|
|
bos@559
|
1676
|
|
bos@559
|
1677 <para>See also: <literal role="hook">preoutgoing</literal>
|
|
bos@559
|
1678 (section <xref linkend="sec:hook:preoutgoing"/>)
|
|
bos@559
|
1679 </para>
|
|
bos@559
|
1680
|
|
bos@559
|
1681 </sect2>
|
|
bos@559
|
1682 <sect2 id="sec:hook:prechangegroup">
|
|
bos@559
|
1683 <title><literal
|
|
bos@559
|
1684 role="hook">prechangegroup</literal>&emdash;before starting
|
|
bos@559
|
1685 to add remote changesets</title>
|
|
bos@559
|
1686
|
|
bos@559
|
1687 <para>This controlling hook is run before Mercurial begins to
|
|
bos@559
|
1688 add a group of changesets from another repository.
|
|
bos@559
|
1689 </para>
|
|
bos@559
|
1690
|
|
bos@559
|
1691 <para>This hook does not have any information about the
|
|
bos@559
|
1692 changesets to be added, because it is run before transmission
|
|
bos@559
|
1693 of those changesets is allowed to begin. If this hook fails,
|
|
bos@559
|
1694 the changesets will not be transmitted.
|
|
bos@559
|
1695 </para>
|
|
bos@559
|
1696
|
|
bos@559
|
1697 <para>One use for this hook is to prevent external changes from
|
|
bos@559
|
1698 being added to a repository. For example, you could use this
|
|
bos@559
|
1699 to <quote>freeze</quote> a server-hosted branch temporarily or
|
|
bos@559
|
1700 permanently so that users cannot push to it, while still
|
|
bos@559
|
1701 allowing a local administrator to modify the repository.
|
|
bos@559
|
1702 </para>
|
|
bos@559
|
1703
|
|
bos@559
|
1704 <para>Parameters to this hook:
|
|
bos@559
|
1705 </para>
|
|
bos@559
|
1706 <itemizedlist>
|
|
bos@559
|
1707 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1708 source of these changes. See section <xref
|
|
bos@559
|
1709 linkend="sec:hook:sources"/> for details.
|
|
bos@559
|
1710 </para>
|
|
bos@559
|
1711 </listitem>
|
|
bos@559
|
1712 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1713 of the remote repository, if known. See section <xref
|
|
bos@559
|
1714 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1715 information.
|
|
bos@559
|
1716 </para>
|
|
bos@559
|
1717 </listitem></itemizedlist>
|
|
bos@559
|
1718
|
|
bos@559
|
1719 <para>See also: <literal role="hook">changegroup</literal>
|
|
bos@559
|
1720 (section <xref linkend="sec:hook:changegroup"/>), <literal
|
|
bos@559
|
1721 role="hook">incoming</literal> (section <xref
|
|
bos@559
|
1722 linkend="sec:hook:incoming"/>), , <literal
|
|
bos@559
|
1723 role="hook">pretxnchangegroup</literal> (section <xref
|
|
bos@559
|
1724 linkend="sec:hook:pretxnchangegroup"/>)
|
|
bos@559
|
1725 </para>
|
|
bos@559
|
1726
|
|
bos@559
|
1727 </sect2>
|
|
bos@559
|
1728 <sect2 id="sec:hook:precommit">
|
|
bos@559
|
1729 <title><literal role="hook">precommit</literal>&emdash;before
|
|
bos@559
|
1730 starting to commit a changeset</title>
|
|
bos@559
|
1731
|
|
bos@559
|
1732 <para>This hook is run before Mercurial begins to commit a new
|
|
bos@559
|
1733 changeset. It is run before Mercurial has any of the metadata
|
|
bos@559
|
1734 for the commit, such as the files to be committed, the commit
|
|
bos@559
|
1735 message, or the commit date.
|
|
bos@559
|
1736 </para>
|
|
bos@559
|
1737
|
|
bos@559
|
1738 <para>One use for this hook is to disable the ability to commit
|
|
bos@559
|
1739 new changesets, while still allowing incoming changesets.
|
|
bos@559
|
1740 Another is to run a build or test, and only allow the commit
|
|
bos@559
|
1741 to begin if the build or test succeeds.
|
|
bos@559
|
1742 </para>
|
|
bos@559
|
1743
|
|
bos@559
|
1744 <para>Parameters to this hook:
|
|
bos@559
|
1745 </para>
|
|
bos@559
|
1746 <itemizedlist>
|
|
bos@559
|
1747 <listitem><para><literal>parent1</literal>: A changeset ID.
|
|
bos@559
|
1748 The changeset ID of the first parent of the working
|
|
bos@559
|
1749 directory.
|
|
bos@559
|
1750 </para>
|
|
bos@559
|
1751 </listitem>
|
|
bos@559
|
1752 <listitem><para><literal>parent2</literal>: A changeset ID.
|
|
bos@559
|
1753 The changeset ID of the second parent of the working
|
|
bos@559
|
1754 directory.
|
|
bos@559
|
1755 </para>
|
|
bos@559
|
1756 </listitem></itemizedlist>
|
|
bos@559
|
1757 <para>If the commit proceeds, the parents of the working
|
|
bos@559
|
1758 directory will become the parents of the new changeset.
|
|
bos@559
|
1759 </para>
|
|
bos@559
|
1760
|
|
bos@559
|
1761 <para>See also: <literal role="hook">commit</literal> (section
|
|
bos@559
|
1762 <xref linkend="sec:hook:commit"/>), <literal
|
|
bos@559
|
1763 role="hook">pretxncommit</literal> (section <xref
|
|
bos@559
|
1764 linkend="sec:hook:pretxncommit"/>)
|
|
bos@559
|
1765 </para>
|
|
bos@559
|
1766
|
|
bos@559
|
1767 </sect2>
|
|
bos@559
|
1768 <sect2 id="sec:hook:preoutgoing">
|
|
bos@559
|
1769 <title><literal role="hook">preoutgoing</literal>&emdash;before
|
|
bos@559
|
1770 starting to propagate changesets</title>
|
|
bos@559
|
1771
|
|
bos@559
|
1772 <para>This hook is invoked before Mercurial knows the identities
|
|
bos@559
|
1773 of the changesets to be transmitted.
|
|
bos@559
|
1774 </para>
|
|
bos@559
|
1775
|
|
bos@559
|
1776 <para>One use for this hook is to prevent changes from being
|
|
bos@559
|
1777 transmitted to another repository.
|
|
bos@559
|
1778 </para>
|
|
bos@559
|
1779
|
|
bos@559
|
1780 <para>Parameters to this hook:
|
|
bos@559
|
1781 </para>
|
|
bos@559
|
1782 <itemizedlist>
|
|
bos@559
|
1783 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1784 source of the operation that is attempting to obtain
|
|
bos@559
|
1785 changes from this repository (see section <xref
|
|
bos@559
|
1786 linkend="sec:hook:sources"/>). See the documentation
|
|
bos@559
|
1787 for the <literal>source</literal> parameter to the
|
|
bos@559
|
1788 <literal role="hook">outgoing</literal> hook, in section
|
|
bos@559
|
1789 <xref linkend="sec:hook:outgoing"/>, for possible values
|
|
bos@559
|
1790 of
|
|
bos@559
|
1791 this parameter.
|
|
bos@559
|
1792 </para>
|
|
bos@559
|
1793 </listitem>
|
|
bos@559
|
1794 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1795 of the remote repository, if known. See section <xref
|
|
bos@559
|
1796 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1797 information.
|
|
bos@559
|
1798 </para>
|
|
bos@559
|
1799 </listitem></itemizedlist>
|
|
bos@559
|
1800
|
|
bos@559
|
1801 <para>See also: <literal role="hook">outgoing</literal> (section
|
|
bos@559
|
1802 <xref linkend="sec:hook:outgoing"/>)
|
|
bos@559
|
1803 </para>
|
|
bos@559
|
1804
|
|
bos@559
|
1805 </sect2>
|
|
bos@559
|
1806 <sect2 id="sec:hook:pretag">
|
|
bos@559
|
1807 <title><literal role="hook">pretag</literal>&emdash;before
|
|
bos@559
|
1808 tagging a changeset</title>
|
|
bos@559
|
1809
|
|
bos@559
|
1810 <para>This controlling hook is run before a tag is created. If
|
|
bos@559
|
1811 the hook succeeds, creation of the tag proceeds. If the hook
|
|
bos@559
|
1812 fails, the tag is not created.
|
|
bos@559
|
1813 </para>
|
|
bos@559
|
1814
|
|
bos@559
|
1815 <para>Parameters to this hook:
|
|
bos@559
|
1816 </para>
|
|
bos@559
|
1817 <itemizedlist>
|
|
bos@559
|
1818 <listitem><para><literal>local</literal>: A boolean. Whether
|
|
bos@559
|
1819 the tag is local to this repository instance (i.e. stored
|
|
bos@559
|
1820 in <filename role="special">.hg/localtags</filename>) or
|
|
bos@559
|
1821 managed by Mercurial (stored in <filename
|
|
bos@559
|
1822 role="special">.hgtags</filename>).
|
|
bos@559
|
1823 </para>
|
|
bos@559
|
1824 </listitem>
|
|
bos@559
|
1825 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1826 ID of the changeset to be tagged.
|
|
bos@559
|
1827 </para>
|
|
bos@559
|
1828 </listitem>
|
|
bos@559
|
1829 <listitem><para><literal>tag</literal>: A string. The name of
|
|
bos@559
|
1830 the tag to be created.
|
|
bos@559
|
1831 </para>
|
|
bos@559
|
1832 </listitem></itemizedlist>
|
|
bos@559
|
1833
|
|
bos@559
|
1834 <para>If the tag to be created is revision-controlled, the
|
|
bos@559
|
1835 <literal role="hook">precommit</literal> and <literal
|
|
bos@559
|
1836 role="hook">pretxncommit</literal> hooks (sections <xref
|
|
bos@559
|
1837 linkend="sec:hook:commit"/> and <xref
|
|
bos@559
|
1838 linkend="sec:hook:pretxncommit"/>) will also be run.
|
|
bos@559
|
1839 </para>
|
|
bos@559
|
1840
|
|
bos@559
|
1841 <para>See also: <literal role="hook">tag</literal> (section
|
|
bos@559
|
1842 <xref linkend="sec:hook:tag"/>)
|
|
bos@559
|
1843 </para>
|
|
bos@559
|
1844 </sect2>
|
|
bos@559
|
1845 <sect2 id="sec:hook:pretxnchangegroup">
|
|
bos@559
|
1846 <title><literal
|
|
bos@559
|
1847 role="hook">pretxnchangegroup</literal>&emdash;before
|
|
bos@559
|
1848 completing addition of remote changesets</title>
|
|
bos@559
|
1849
|
|
bos@559
|
1850 <para>This controlling hook is run before a
|
|
bos@559
|
1851 transaction&emdash;that manages the addition of a group of new
|
|
bos@559
|
1852 changesets from outside the repository&emdash;completes. If
|
|
bos@559
|
1853 the hook succeeds, the transaction completes, and all of the
|
|
bos@559
|
1854 changesets become permanent within this repository. If the
|
|
bos@559
|
1855 hook fails, the transaction is rolled back, and the data for
|
|
bos@559
|
1856 the changesets is erased.
|
|
bos@559
|
1857 </para>
|
|
bos@559
|
1858
|
|
bos@559
|
1859 <para>This hook can access the metadata associated with the
|
|
bos@559
|
1860 almost-added changesets, but it should not do anything
|
|
bos@559
|
1861 permanent with this data. It must also not modify the working
|
|
bos@559
|
1862 directory.
|
|
bos@559
|
1863 </para>
|
|
bos@559
|
1864
|
|
bos@559
|
1865 <para>While this hook is running, if other Mercurial processes
|
|
bos@559
|
1866 access this repository, they will be able to see the
|
|
bos@559
|
1867 almost-added changesets as if they are permanent. This may
|
|
bos@559
|
1868 lead to race conditions if you do not take steps to avoid
|
|
bos@559
|
1869 them.
|
|
bos@559
|
1870 </para>
|
|
bos@559
|
1871
|
|
bos@559
|
1872 <para>This hook can be used to automatically vet a group of
|
|
bos@559
|
1873 changesets. If the hook fails, all of the changesets are
|
|
bos@559
|
1874 <quote>rejected</quote> when the transaction rolls back.
|
|
bos@559
|
1875 </para>
|
|
bos@559
|
1876
|
|
bos@559
|
1877 <para>Parameters to this hook:
|
|
bos@559
|
1878 </para>
|
|
bos@559
|
1879 <itemizedlist>
|
|
bos@559
|
1880 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1881 changeset ID of the first changeset in the group that was
|
|
bos@559
|
1882 added. All changesets between this and
|
|
bos@559
|
1883 \index{tags!<literal>tip</literal>}<literal>tip</literal>,
|
|
bos@559
|
1884 inclusive, were added by a single <command
|
|
bos@559
|
1885 role="hg-cmd">hg pull</command>, <command
|
|
bos@559
|
1886 role="hg-cmd">hg push</command> or <command
|
|
bos@559
|
1887 role="hg-cmd">hg unbundle</command>.
|
|
bos@559
|
1888 </para>
|
|
bos@559
|
1889 </listitem>
|
|
bos@559
|
1890 <listitem><para><literal>source</literal>: A string. The
|
|
bos@559
|
1891 source of these changes. See section <xref
|
|
bos@559
|
1892 linkend="sec:hook:sources"/> for details.
|
|
bos@559
|
1893 </para>
|
|
bos@559
|
1894 </listitem>
|
|
bos@559
|
1895 <listitem><para><literal>url</literal>: A URL. The location
|
|
bos@559
|
1896 of the remote repository, if known. See section <xref
|
|
bos@559
|
1897 linkend="sec:hook:url"/> for more
|
|
bos@559
|
1898 information.
|
|
bos@559
|
1899 </para>
|
|
bos@559
|
1900 </listitem></itemizedlist>
|
|
bos@559
|
1901
|
|
bos@559
|
1902 <para>See also: <literal role="hook">changegroup</literal>
|
|
bos@559
|
1903 (section <xref linkend="sec:hook:changegroup"/>), <literal
|
|
bos@559
|
1904 role="hook">incoming</literal> (section <xref
|
|
bos@559
|
1905 linkend="sec:hook:incoming"/>), <literal
|
|
bos@559
|
1906 role="hook">prechangegroup</literal> (section <xref
|
|
bos@559
|
1907 linkend="sec:hook:prechangegroup"/>)
|
|
bos@559
|
1908 </para>
|
|
bos@559
|
1909
|
|
bos@559
|
1910 </sect2>
|
|
bos@559
|
1911 <sect2 id="sec:hook:pretxncommit">
|
|
bos@559
|
1912 <title><literal role="hook">pretxncommit</literal>&emdash;before
|
|
bos@559
|
1913 completing commit of new changeset</title>
|
|
bos@559
|
1914
|
|
bos@559
|
1915 <para>This controlling hook is run before a
|
|
bos@559
|
1916 transaction&emdash;that manages a new commit&emdash;completes.
|
|
bos@559
|
1917 If the hook succeeds, the transaction completes and the
|
|
bos@559
|
1918 changeset becomes permanent within this repository. If the
|
|
bos@559
|
1919 hook fails, the transaction is rolled back, and the commit
|
|
bos@559
|
1920 data is erased.
|
|
bos@559
|
1921 </para>
|
|
bos@559
|
1922
|
|
bos@559
|
1923 <para>This hook can access the metadata associated with the
|
|
bos@559
|
1924 almost-new changeset, but it should not do anything permanent
|
|
bos@559
|
1925 with this data. It must also not modify the working
|
|
bos@559
|
1926 directory.
|
|
bos@559
|
1927 </para>
|
|
bos@559
|
1928
|
|
bos@559
|
1929 <para>While this hook is running, if other Mercurial processes
|
|
bos@559
|
1930 access this repository, they will be able to see the
|
|
bos@559
|
1931 almost-new changeset as if it is permanent. This may lead to
|
|
bos@559
|
1932 race conditions if you do not take steps to avoid them.
|
|
bos@559
|
1933 </para>
|
|
bos@559
|
1934
|
|
bos@559
|
1935 <para>Parameters to this hook:
|
|
bos@559
|
1936 </para>
|
|
bos@559
|
1937 <itemizedlist>
|
|
bos@559
|
1938 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
1939 changeset ID of the newly committed changeset.
|
|
bos@559
|
1940 </para>
|
|
bos@559
|
1941 </listitem>
|
|
bos@559
|
1942 <listitem><para><literal>parent1</literal>: A changeset ID.
|
|
bos@559
|
1943 The changeset ID of the first parent of the newly
|
|
bos@559
|
1944 committed changeset.
|
|
bos@559
|
1945 </para>
|
|
bos@559
|
1946 </listitem>
|
|
bos@559
|
1947 <listitem><para><literal>parent2</literal>: A changeset ID.
|
|
bos@559
|
1948 The changeset ID of the second parent of the newly
|
|
bos@559
|
1949 committed changeset.
|
|
bos@559
|
1950 </para>
|
|
bos@559
|
1951 </listitem></itemizedlist>
|
|
bos@559
|
1952
|
|
bos@559
|
1953 <para>See also: <literal role="hook">precommit</literal>
|
|
bos@559
|
1954 (section <xref linkend="sec:hook:precommit"/>)
|
|
bos@559
|
1955 </para>
|
|
bos@559
|
1956
|
|
bos@559
|
1957 </sect2>
|
|
bos@559
|
1958 <sect2 id="sec:hook:preupdate">
|
|
bos@559
|
1959 <title><literal role="hook">preupdate</literal>&emdash;before
|
|
bos@559
|
1960 updating or merging working directory</title>
|
|
bos@559
|
1961
|
|
bos@559
|
1962 <para>This controlling hook is run before an update or merge of
|
|
bos@559
|
1963 the working directory begins. It is run only if Mercurial's
|
|
bos@559
|
1964 normal pre-update checks determine that the update or merge
|
|
bos@559
|
1965 can proceed. If the hook succeeds, the update or merge may
|
|
bos@559
|
1966 proceed; if it fails, the update or merge does not start.
|
|
bos@559
|
1967 </para>
|
|
bos@559
|
1968
|
|
bos@559
|
1969 <para>Parameters to this hook:
|
|
bos@559
|
1970 </para>
|
|
bos@559
|
1971 <itemizedlist>
|
|
bos@559
|
1972 <listitem><para><literal>parent1</literal>: A changeset ID.
|
|
bos@559
|
1973 The ID of the parent that the working directory is to be
|
|
bos@559
|
1974 updated to. If the working directory is being merged, it
|
|
bos@559
|
1975 will not change this parent.
|
|
bos@559
|
1976 </para>
|
|
bos@559
|
1977 </listitem>
|
|
bos@559
|
1978 <listitem><para><literal>parent2</literal>: A changeset ID.
|
|
bos@559
|
1979 Only set if the working directory is being merged. The ID
|
|
bos@559
|
1980 of the revision that the working directory is being merged
|
|
bos@559
|
1981 with.
|
|
bos@559
|
1982 </para>
|
|
bos@559
|
1983 </listitem></itemizedlist>
|
|
bos@559
|
1984
|
|
bos@559
|
1985 <para>See also: <literal role="hook">update</literal> (section
|
|
bos@559
|
1986 <xref linkend="sec:hook:update"/>)
|
|
bos@559
|
1987 </para>
|
|
bos@559
|
1988
|
|
bos@559
|
1989 </sect2>
|
|
bos@559
|
1990 <sect2 id="sec:hook:tag">
|
|
bos@559
|
1991 <title><literal role="hook">tag</literal>&emdash;after tagging a
|
|
bos@559
|
1992 changeset</title>
|
|
bos@559
|
1993
|
|
bos@559
|
1994 <para>This hook is run after a tag has been created.
|
|
bos@559
|
1995 </para>
|
|
bos@559
|
1996
|
|
bos@559
|
1997 <para>Parameters to this hook:
|
|
bos@559
|
1998 </para>
|
|
bos@559
|
1999 <itemizedlist>
|
|
bos@559
|
2000 <listitem><para><literal>local</literal>: A boolean. Whether
|
|
bos@559
|
2001 the new tag is local to this repository instance (i.e.
|
|
bos@559
|
2002 stored in <filename
|
|
bos@559
|
2003 role="special">.hg/localtags</filename>) or managed by
|
|
bos@559
|
2004 Mercurial (stored in <filename
|
|
bos@559
|
2005 role="special">.hgtags</filename>).
|
|
bos@559
|
2006 </para>
|
|
bos@559
|
2007 </listitem>
|
|
bos@559
|
2008 <listitem><para><literal>node</literal>: A changeset ID. The
|
|
bos@559
|
2009 ID of the changeset that was tagged.
|
|
bos@559
|
2010 </para>
|
|
bos@559
|
2011 </listitem>
|
|
bos@559
|
2012 <listitem><para><literal>tag</literal>: A string. The name of
|
|
bos@559
|
2013 the tag that was created.
|
|
bos@559
|
2014 </para>
|
|
bos@559
|
2015 </listitem></itemizedlist>
|
|
bos@559
|
2016
|
|
bos@559
|
2017 <para>If the created tag is revision-controlled, the <literal
|
|
bos@559
|
2018 role="hook">commit</literal> hook (section <xref
|
|
bos@559
|
2019 linkend="sec:hook:commit"/>) is run before this hook.
|
|
bos@559
|
2020 </para>
|
|
bos@559
|
2021
|
|
bos@559
|
2022 <para>See also: <literal role="hook">pretag</literal> (section
|
|
bos@559
|
2023 <xref linkend="sec:hook:pretag"/>)
|
|
bos@559
|
2024 </para>
|
|
bos@559
|
2025
|
|
bos@559
|
2026 </sect2>
|
|
bos@559
|
2027 <sect2 id="sec:hook:update">
|
|
bos@559
|
2028 <title><literal role="hook">update</literal>&emdash;after
|
|
bos@559
|
2029 updating or merging working directory</title>
|
|
bos@559
|
2030
|
|
bos@559
|
2031 <para>This hook is run after an update or merge of the working
|
|
bos@559
|
2032 directory completes. Since a merge can fail (if the external
|
|
bos@559
|
2033 <command>hgmerge</command> command fails to resolve conflicts
|
|
bos@559
|
2034 in a file), this hook communicates whether the update or merge
|
|
bos@559
|
2035 completed cleanly.
|
|
bos@559
|
2036 </para>
|
|
bos@559
|
2037
|
|
bos@559
|
2038 <itemizedlist>
|
|
bos@559
|
2039 <listitem><para><literal>error</literal>: A boolean.
|
|
bos@559
|
2040 Indicates whether the update or merge completed
|
|
bos@559
|
2041 successfully.
|
|
bos@559
|
2042 </para>
|
|
bos@559
|
2043 </listitem>
|
|
bos@559
|
2044 <listitem><para><literal>parent1</literal>: A changeset ID.
|
|
bos@559
|
2045 The ID of the parent that the working directory was
|
|
bos@559
|
2046 updated to. If the working directory was merged, it will
|
|
bos@559
|
2047 not have changed this parent.
|
|
bos@559
|
2048 </para>
|
|
bos@559
|
2049 </listitem>
|
|
bos@559
|
2050 <listitem><para><literal>parent2</literal>: A changeset ID.
|
|
bos@559
|
2051 Only set if the working directory was merged. The ID of
|
|
bos@559
|
2052 the revision that the working directory was merged with.
|
|
bos@559
|
2053 </para>
|
|
bos@559
|
2054 </listitem></itemizedlist>
|
|
bos@559
|
2055
|
|
bos@559
|
2056 <para>See also: <literal role="hook">preupdate</literal>
|
|
bos@559
|
2057 (section <xref linkend="sec:hook:preupdate"/>)
|
|
bos@559
|
2058 </para>
|
|
bos@559
|
2059
|
|
bos@559
|
2060 </sect2>
|
|
bos@559
|
2061 </sect1>
|
|
bos@559
|
2062 </chapter>
|
|
bos@559
|
2063
|
|
bos@559
|
2064 <!--
|
|
bos@559
|
2065 local variables:
|
|
bos@559
|
2066 sgml-parent-document: ("00book.xml" "book" "chapter")
|
|
bos@559
|
2067 end:
|
|
bos@559
|
2068 -->
|
