Mercurial > hgbook
annotate ja/tour-merge.tex @ 365:427e0fed6d5e
started tour-merge.tex
author | Yoshiki Yazawa <yaz@honeyplanet.jp> |
---|---|
date | Mon, 20 Oct 2008 17:22:47 +0900 |
parents | 3b1291f24c0d |
children | 4e746f46085c |
rev | line source |
---|---|
365 | 1 %\chapter{A tour of Mercurial: merging work} |
2 \chapter{Mercurial$B%D%"!<(B: $B%^!<%8(B} | |
95
47ea206351d5
Split tour into two sections.
Bryan O'Sullivan <bos@serpentine.com>
parents:
94
diff
changeset
|
3 \label{chap:tour-merge} |
94 | 4 |
365 | 5 %We've now covered cloning a repository, making changes in a |
6 %repository, and pulling or pushing changes from one repository into | |
7 %another. Our next step is \emph{merging} changes from separate | |
8 %repositories. | |
9 | |
10 $B2f!9$O4{$K%j%]%8%H%j$N%/%m!<%s!$%j%]%8%H%j$KBP$9$kJQ99!$(B1$B$D$N%j%]%8%H%j$+(B | |
11 $B$i$N(Bpull$B$HJL$N(B1$B$D$N%j%]%8%H%j$KBP$9$k(Bpush$B$r9T$C$?!%<!$N%9%F%C%W$OJL$N%j%](B | |
12 $B%8%H%j$+$iJQ99$r(B\emph{$B%^!<%8(B}$B$9$k$3$H$G$"$k!%(B | |
94 | 13 |
365 | 14 %\section{Merging streams of work} |
15 \section{$BJ#?t$N:n6H7k2L$r%^!<%8$9$k(B} | |
16 | |
17 %Merging is a fundamental part of working with a distributed revision | |
18 %control tool. | |
19 | |
20 $B%^!<%8$OJ,;6%j%S%8%g%s%3%s%H%m!<%k%D!<%k$G$N:n6H$K$*$$$FIT2D7g$NItJ,$G$"(B | |
21 $B$k!%(B | |
95
47ea206351d5
Split tour into two sections.
Bryan O'Sullivan <bos@serpentine.com>
parents:
94
diff
changeset
|
22 |
94 | 23 \begin{itemize} |
365 | 24 %\item Alice and Bob each have a personal copy of a repository for a |
25 | |
26 % project they're collaborating on. Alice fixes a bug in her | |
27 % repository; Bob adds a new feature in his. They want the shared | |
28 % repository to contain both the bug fix and the new feature. | |
29 \item $B%"%j%9$H%\%V$O6&F1:n6H$7$F$$$k%W%m%8%'%/%H$N%j%]%8%H%j%3%T!<$r3F!9(B | |
30 $B;}$C$F$$$k!%%"%j%9$O<+J,$N%j%]%8%H%j$G%P%0$r=$@5$7!$%\%V$OH`$N%j%]%8%H%j(B | |
31 $B$G?75!G=$rDI2C$7$?!%H`$i$O%P%0=$@5$H?75!G=$NN>J}$r;}$D%j%]%8%H%j$r6&M-$7(B | |
32 $B$?$$$H9M$($F$$$k!%(B | |
33 | |
34 %\item I frequently work on several different tasks for a single | |
35 % project at once, each safely isolated in its own repository. | |
36 % Working this way means that I often need to merge one piece of my | |
37 % own work with another. | |
38 \item $B;d$O0l$D$N%W%m%8%'%/%H$NJL!9$N%?%9%/$KBP$7$FF1;~$K:n6H$r9T$&$3$H$r(B | |
39 $B$h$/9T$C$F$$$k!%$3$N$h$&$J:n6H%9%?%$%k$G$O!$<+J,$N:n6H$N0l$D$+$iJL(B | |
40 $B$N:n6H$N0l$D$X7k2L$r%^!<%8$7$?$$$H;W$&$3$H$,$7$P$7$P$"$k!%(B | |
41 | |
94 | 42 \end{itemize} |
43 | |
365 | 44 %Because merging is such a common thing to need to do, Mercurial makes |
45 %it easy. Let's walk through the process. We'll begin by cloning yet | |
46 %another repository (see how often they spring up?) and making a change | |
47 %in it. | |
48 | |
49 $B>e$G=R$Y$?$h$&$K%^!<%8$r9T$$$?$$>u67$O$H$F$bB?$$$?$a!$(B Mercurial$B$G$O%^!<(B | |
50 $B%8$r4JC1$K9T$($k$h$&$K$J$C$F$$$k!%$^$:JL$N%j%]%8%H%j$r%/%m!<%s$7!$JQ99$r(B | |
51 $B2C$($k$H$3$m$+$i;O$a$h$&!%(B | |
94 | 52 \interaction{tour.merge.clone} |
365 | 53 |
54 %We should now have two copies of \filename{hello.c} with different | |
55 %contents. The histories of the two repositories have also diverged, | |
56 %as illustrated in figure~\ref{fig:tour-merge:sep-repos}. | |
57 | |
58 $B:#!$FbMF$N0[$J$C$?(B2$B$D$N(B\filename{hello.c}$B$,$"$k!%(B 2$B$D$N%j%]%8%H%j$NMzNr$O(B | |
59 $B?^(B~\ref{fig:tour-merge:sep-repos}$B$K<($9$h$&$KJ,$+$l$F$$$k!%(B | |
94 | 60 \interaction{tour.merge.cat} |
61 | |
99 | 62 \begin{figure}[ht] |
63 \centering | |
64 \grafix{tour-merge-sep-repos} | |
365 | 65 % \caption{Divergent recent histories of the \dirname{my-hello} and |
66 % \dirname{my-new-hello} repositories} | |
67 \caption{\dirname{my-hello}$B%j%]%8%H%j$H(B\dirname{my-new-hello}$B%j%]%8%H(B | |
68 $B%j$NMzNr$N:90[(B} | |
99 | 69 \label{fig:tour-merge:sep-repos} |
70 \end{figure} | |
71 | |
365 | 72 %We already know that pulling changes from our \dirname{my-hello} |
73 %repository will have no effect on the working directory. | |
74 $B4{$K(B\dirname{my-hello}$B%j%]%8%H%j$+$i$N(Bpull$B$O%o!<%-%s%0%G%#%l%/%H%j$K2?$N(B | |
75 $B1F6A$bM?$($J$$$3$H$r3X$s$@!%(B | |
94 | 76 \interaction{tour.merge.pull} |
365 | 77 %However, the \hgcmd{pull} command says something about ``heads''. |
78 $B$7$+$7(B\hgcmd{pull}$B%3%^%s%I$O(B``heads''$B$K$D$$$F%a%C%;!<%8$rI=<($9$k!%(B | |
94 | 79 |
365 | 80 %\subsection{Head changesets} |
81 \subsection{Head$B%A%'%s%8%;%C%H(B} | |
102 | 82 |
365 | 83 %A head is a change that has no descendants, or children, as they're |
84 %also known. The tip revision is thus a head, because the newest | |
85 %revision in a repository doesn't have any children, but a repository | |
86 %can contain more than one head. | |
87 head$B$O;RB9$d;R$r;}$?$J$$JQ99$G$"$k!%%j%]%8%H%j$N:G?7$N%j%S%8%g%s$O;R$r;}(B | |
88 $B$?$J$$$?$a!$(Btip$B%j%S%8%g%s$O$9$J$o$A(Bhead$B$G$"$k!%0lJ}$G%j%]%8%H%j$OJ#?t$N(B | |
89 head$B$r;}$AF@$k!%(B | |
99 | 90 |
91 \begin{figure}[ht] | |
92 \centering | |
93 \grafix{tour-merge-pull} | |
365 | 94 % \caption{Repository contents after pulling from \dirname{my-hello} into |
95 % \dirname{my-new-hello}} | |
96 \caption{\dirname{my-hello}$B$+$i(B\dirname{my-new-hello}$B$X(Bpull$B$7$?$"$H$N(B | |
97 $B%j%]%8%H%j$NFbMF(B} | |
99 | 98 \label{fig:tour-merge:pull} |
99 \end{figure} | |
100 | |
365 | 101 %In figure~\ref{fig:tour-merge:pull}, you can see the effect of the |
102 %pull from \dirname{my-hello} into \dirname{my-new-hello}. The history | |
103 %that was already present in \dirname{my-new-hello} is untouched, but a | |
104 %new revision has been added. By referring to | |
105 %figure~\ref{fig:tour-merge:sep-repos}, we can see that the | |
106 %\emph{changeset ID} remains the same in the new repository, but the | |
107 %\emph{revision number} has changed. (This, incidentally, is a fine | |
108 %example of why it's not safe to use revision numbers when discussing | |
109 %changesets.) We can view the heads in a repository using the | |
110 %\hgcmd{heads} command. | |
111 %\interaction{tour.merge.heads} | |
112 | |
113 $B?^(B~\ref{fig:tour-merge:pull}$B$K(B\dirname{my-hello}$B$+$i(B | |
114 \dirname{my-new-hello}$B$X(Bpull$B$r9T$C$?8z2L$r<($9!%(B \dirname{my-new-hello}$B$K(B | |
115 $B4{$KB8:_$7$?MzNr$OJQ99$5$l$:!$?7$?$K%j%S%8%g%s$,DI2C$5$l$k!%(B | |
116 figure~\ref{fig:tour-merge:sep-repos}$B$r8+$k$H!$?7$7$$%j%]%8%H%j$K$b(B | |
117 \emph{changeset ID}$B$,;D$C$F$$$k$3$H!$(B\emph{$B%j%S%8%g%sHV9f(B}$B$,JQ99$5$l$F$$(B | |
118 $B$k$3$H$,J,$+$k!%(B $B!J$3$l$OF1;~$K%A%'%s%8%;%C%H$K$D$$$FO@$8$k:]$K%j%S%8%g%s(B | |
119 $BHV9f$rMQ$$$k$N$,0BA4$G$J$$$3$H$NNc$K$J$C$F$$$k!%!K%j%]%8%H%jFb$K$"$k(Bhead | |
120 $B$O(B\hgcmd{heads}$B$K$h$C$F8+$k$3$H$,$G$-$k!%(B | |
94 | 121 \interaction{tour.merge.heads} |
102 | 122 |
365 | 123 %\subsection{Performing the merge} |
124 \subsection{$B%^!<%8$r<B9T$9$k(B} | |
102 | 125 |
365 | 126 %What happens if we try to use the normal \hgcmd{update} command to |
127 %update to the new tip? | |
128 %\interaction{tour.merge.update} | |
129 | |
130 $B?7$7$$(Btip$B$X99?7$9$k$?$a$K(B\hgcmd{update}$B$r;H$C$?>l9g2?$,5/$-$k$+!)(B | |
94 | 131 \interaction{tour.merge.update} |
365 | 132 |
133 %Mercurial is telling us that the \hgcmd{update} command won't do a | |
134 %merge; it won't update the working directory when it thinks we might | |
135 %be wanting to do a merge, unless we force it to do so. Instead, we | |
136 %use the \hgcmd{merge} command to merge the two heads. | |
137 %\interaction{tour.merge.merge} | |
138 | |
139 Mercurial$B$O(B\hgcmd{update}$B%3%^%s%I$,%^!<%8$r9T$o$J$$$H%a%C%;!<%8$rI=<($9(B | |
140 $B$k!%(B \hgcmd{update}$B%3%^%s%I$O!$%^!<%8$,I,MW$H9M$($i$l$k>l9g$O!$%f!<%6$,(B | |
141 $B!J%*%W%7%g%s$K$h$C$F!K6/@)$7$J$$8B$j%o!<%-%s%0%G%#%l%/%H%j$r99?7$7$J$$!%(B | |
142 $B0lJ}!$(B\hgcmd{merge}$B%3%^%s%I$O(B2$B$D$N%X%C%I$N%^!<%8$r9T$&!%(B | |
94 | 143 \interaction{tour.merge.merge} |
100
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
144 |
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
145 \begin{figure}[ht] |
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
146 \centering |
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
147 \grafix{tour-merge-merge} |
365 | 148 % \caption{Working directory and repository during merge, and |
149 % following commit} | |
150 \caption{$B%^!<%8Cf$N%o!<%-%s%0%G%#%l%/%H%j$H%j%]%8%H%j$*$h$S8eB3$N%3%_%C(B | |
151 $B%H(B} | |
100
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
152 \label{fig:tour-merge:merge} |
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
153 \end{figure} |
272146fab009
Add yet another illustration of the merge process.
Bryan O'Sullivan <bos@serpentine.com>
parents:
99
diff
changeset
|
154 |
365 | 155 %This updates the working directory so that it contains changes from |
156 %\emph{both} heads, which is reflected in both the output of | |
157 %\hgcmd{parents} and the contents of \filename{hello.c}. | |
158 %\interaction{tour.merge.parents} | |
159 | |
160 $B$3$NA`:n$K$h$C$F(B\hgcmd{parents}$B$H(B\filename{hello.c}$B$N=PNO$NAPJ}$rH?1G$9$k(B | |
161 \emph{$BAPJ}$N(B}head$B$+$i$NJQ99$r4^$`$h$&$K%o!<%-%s%0%G%#%l%/%H%j$,99?7$5$l$k!%(B | |
102 | 162 |
365 | 163 %\subsection{Committing the results of the merge} |
164 \subsection{$B%^!<%87k2L$r%3%_%C%H$9$k(B} | |
102 | 165 |
365 | 166 %Whenever we've done a merge, \hgcmd{parents} will display two parents |
167 %until we \hgcmd{commit} the results of the merge. | |
168 %\interaction{tour.merge.commit} | |
169 | |
170 $B%^!<%8$r9T$&$H!$%^!<%8$N7k2L$r(B\hgcmd{commit}$B$9$k$^$G!$(B\hgcmd{parents}$B$O(B2 | |
171 $B$D$N%Z%"%l%s%H$rI=<($9$k!%(B | |
94 | 172 \interaction{tour.merge.commit} |
365 | 173 |
174 %We now have a new tip revision; notice that it has \emph{both} of | |
175 %our former heads as its parents. These are the same revisions that | |
176 %were previously displayed by \hgcmd{parents}. | |
177 %\interaction{tour.merge.tip} | |
178 | |
179 $B?7$7$$(Btip$B%j%S%8%g%s$O0JA0$N%X%C%I(B\emph{$BN>J}(B}$B$r?F$H$7$F;}$D!%$3$l$i$O(B | |
180 \hgcmd{parents}$B%3%^%s%I$GI=<($7$?$N$HF1$8%j%S%8%g%s$G$"$k!%(B | |
94 | 181 \interaction{tour.merge.tip} |
365 | 182 |
183 %In figure~\ref{fig:tour-merge:merge}, you can see a representation of | |
184 %what happens to the working directory during the merge, and how this | |
185 %affects the repository when the commit happens. During the merge, the | |
186 %working directory has two parent changesets, and these become the | |
187 %parents of the new changeset. | |
94 | 188 |
365 | 189 $B?^(B~\ref{fig:tour-merge:merge}$B$G!$%^!<%8$N4V$K%o!<%-%s%0%G%#%l%/%H%j$K2?$,(B |
190 $B5/$-!$%3%_%C%H$7$?;~$K%j%]%8%H%j$K$I$&1F6A$9$k$N$+$r8+$k$3$H$,$G$-$k!%(B | |
191 $B%^!<%8$N4V!$%o!<%-%s%0%G%#%l%/%H%j$O(B2$B$D$N?F%A%'%s%8%;%C%H$r;}$A!$$3$l$i$O(B | |
192 $B?7$7$$%A%'%s%8%;%C%H$NN>?F$H$J$k!%(B | |
193 | |
194 %\section{Merging conflicting changes} | |
195 \section{$B%3%s%U%j%/%H$N$"$kJQ99$r%^!<%8$9$k(B} | |
102 | 196 |
197 Most merges are simple affairs, but sometimes you'll find yourself | |
103 | 198 merging changes where each modifies the same portions of the same |
199 files. Unless both modifications are identical, this results in a | |
200 \emph{conflict}, where you have to decide how to reconcile the | |
201 different changes into something coherent. | |
202 | |
203 \begin{figure}[ht] | |
204 \centering | |
205 \grafix{tour-merge-conflict} | |
206 \caption{Conflicting changes to a document} | |
207 \label{fig:tour-merge:conflict} | |
208 \end{figure} | |
209 | |
210 Figure~\ref{fig:tour-merge:conflict} illustrates an instance of two | |
211 conflicting changes to a document. We started with a single version | |
212 of the file; then we made some changes; while someone else made | |
213 different changes to the same text. Our task in resolving the | |
214 conflicting changes is to decide what the file should look like. | |
215 | |
216 Mercurial doesn't have a built-in facility for handling conflicts. | |
217 Instead, it runs an external program called \command{hgmerge}. This | |
218 is a shell script that is bundled with Mercurial; you can change it to | |
219 behave however you please. What it does by default is try to find one | |
220 of several different merging tools that are likely to be installed on | |
221 your system. It first tries a few fully automatic merging tools; if | |
222 these don't succeed (because the resolution process requires human | |
223 guidance) or aren't present, the script tries a few different | |
224 graphical merging tools. | |
225 | |
226 It's also possible to get Mercurial to run another program or script | |
227 instead of \command{hgmerge}, by setting the \envar{HGMERGE} | |
228 environment variable to the name of your preferred program. | |
229 | |
365 | 230 %\subsection{Using a graphical merge tool} |
231 \subsection{$B%0%i%U%#%+%k%^!<%8%D!<%k$N;HMQ(B} | |
103 | 232 |
233 My preferred graphical merge tool is \command{kdiff3}, which I'll use | |
234 to describe the features that are common to graphical file merging | |
235 tools. You can see a screenshot of \command{kdiff3} in action in | |
236 figure~\ref{fig:tour-merge:kdiff3}. The kind of merge it is | |
237 performing is called a \emph{three-way merge}, because there are three | |
238 different versions of the file of interest to us. The tool thus | |
239 splits the upper portion of the window into three panes: | |
240 \begin{itemize} | |
241 \item At the left is the \emph{base} version of the file, i.e.~the | |
242 most recent version from which the two versions we're trying to | |
243 merge are descended. | |
244 \item In the middle is ``our'' version of the file, with the contents | |
245 that we modified. | |
246 \item On the right is ``their'' version of the file, the one that | |
247 from the changeset that we're trying to merge with. | |
248 \end{itemize} | |
249 In the pane below these is the current \emph{result} of the merge. | |
250 Our task is to replace all of the red text, which indicates unresolved | |
251 conflicts, with some sensible merger of the ``ours'' and ``theirs'' | |
252 versions of the file. | |
253 | |
254 All four of these panes are \emph{locked together}; if we scroll | |
255 vertically or horizontally in any of them, the others are updated to | |
256 display the corresponding sections of their respective files. | |
102 | 257 |
103 | 258 \begin{figure}[ht] |
259 \centering | |
260 \grafix{kdiff3} | |
365 | 261 % \caption{Using \command{kdiff3} to merge versions of a file} |
262 \caption{$B%U%!%$%k$NJ#?t%j%S%8%g%s$r(B\command{kdiff3}$B$r;H$C$F%^!<%8$9$k(B} | |
103 | 263 \label{fig:tour-merge:kdiff3} |
264 \end{figure} | |
265 | |
266 For each conflicting portion of the file, we can choose to resolve | |
257
d9d29e7cf5bd
fix a couple of over-zealous 'h' key typos
Michael Rowe <mrowe@mojain.com>
parents:
224
diff
changeset
|
267 the conflict using some combination of text from the base version, |
103 | 268 ours, or theirs. We can also manually edit the merged file at any |
269 time, in case we need to make further modifications. | |
270 | |
271 There are \emph{many} file merging tools available, too many to cover | |
272 here. They vary in which platforms they are available for, and in | |
273 their particular strengths and weaknesses. Most are tuned for merging | |
274 files containing plain text, while a few are aimed at specialised file | |
275 formats (generally XML). | |
276 | |
365 | 277 %\subsection{A worked example} |
278 \subsection{$B<B9TNc(B} | |
103 | 279 |
280 In this example, we will reproduce the file modification history of | |
281 figure~\ref{fig:tour-merge:conflict} above. Let's begin by creating a | |
282 repository with a base version of our document. | |
283 \interaction{tour-merge-conflict.wife} | |
284 We'll clone the repository and make a change to the file. | |
285 \interaction{tour-merge-conflict.cousin} | |
286 And another clone, to simulate someone else making a change to the | |
287 file. (This hints at the idea that it's not all that unusual to merge | |
288 with yourself when you isolate tasks in separate repositories, and | |
289 indeed to find and resolve conflicts while doing so.) | |
290 \interaction{tour-merge-conflict.son} | |
291 Having created two different versions of the file, we'll set up an | |
292 environment suitable for running our merge. | |
293 \interaction{tour-merge-conflict.pull} | |
294 | |
295 In this example, I won't use Mercurial's normal \command{hgmerge} | |
296 program to do the merge, because it would drop my nice automated | |
297 example-running tool into a graphical user interface. Instead, I'll | |
298 set \envar{HGMERGE} to tell Mercurial to use the non-interactive | |
299 \command{merge} command. This is bundled with many Unix-like systems. | |
300 If you're following this example on your computer, don't bother | |
301 setting \envar{HGMERGE}. | |
302 \interaction{tour-merge-conflict.merge} | |
303 Because \command{merge} can't resolve the conflicting changes, it | |
304 leaves \emph{merge markers} inside the file that has conflicts, | |
305 indicating which lines have conflicts, and whether they came from our | |
306 version of the file or theirs. | |
307 | |
308 Mercurial can tell from the way \command{merge} exits that it wasn't | |
309 able to merge successfully, so it tells us what commands we'll need to | |
310 run if we want to redo the merging operation. This could be useful | |
311 if, for example, we were running a graphical merge tool and quit | |
312 because we were confused or realised we had made a mistake. | |
313 | |
314 If automatic or manual merges fail, there's nothing to prevent us from | |
315 ``fixing up'' the affected files ourselves, and committing the results | |
316 of our merge: | |
317 \interaction{tour-merge-conflict.commit} | |
318 | |
365 | 319 %\section{Simplifying the pull-merge-commit sequence} |
320 \section{pull-merge-commit$B<j=g$r4JC1$K$9$k(B} | |
224
34943a3d50d6
Start writing up extensions. Begin with inotify.
Bryan O'Sullivan <bos@serpentine.com>
parents:
103
diff
changeset
|
321 \label{sec:tour-merge:fetch} |
102 | 322 |
323 The process of merging changes as outlined above is straightforward, | |
324 but requires running three commands in sequence. | |
325 \begin{codesample2} | |
326 hg pull | |
327 hg merge | |
328 hg commit -m 'Merged remote changes' | |
329 \end{codesample2} | |
103 | 330 In the case of the final commit, you also need to enter a commit |
331 message, which is almost always going to be a piece of uninteresting | |
332 ``boilerplate'' text. | |
102 | 333 |
334 It would be nice to reduce the number of steps needed, if this were | |
335 possible. Indeed, Mercurial is distributed with an extension called | |
336 \hgext{fetch} that does just this. | |
337 | |
338 Mercurial provides a flexible extension mechanism that lets people | |
339 extend its functionality, while keeping the core of Mercurial small | |
340 and easy to deal with. Some extensions add new commands that you can | |
341 use from the command line, while others work ``behind the scenes,'' | |
342 for example adding capabilities to the server. | |
343 | |
344 The \hgext{fetch} extension adds a new command called, not | |
345 surprisingly, \hgcmd{fetch}. This extension acts as a combination of | |
346 \hgcmd{pull}, \hgcmd{update} and \hgcmd{merge}. It begins by pulling | |
347 changes from another repository into the current repository. If it | |
348 finds that the changes added a new head to the repository, it begins a | |
349 merge, then commits the result of the merge with an | |
350 automatically-generated commit message. If no new heads were added, | |
351 it updates the working directory to the new tip changeset. | |
352 | |
353 Enabling the \hgext{fetch} extension is easy. Edit your | |
354 \sfilename{.hgrc}, and either go to the \rcsection{extensions} section | |
355 or create an \rcsection{extensions} section. Then add a line that | |
356 simply reads ``\Verb+fetch +''. | |
357 \begin{codesample2} | |
358 [extensions] | |
359 fetch = | |
360 \end{codesample2} | |
361 (Normally, on the right-hand side of the ``\texttt{=}'' would appear | |
362 the location of the extension, but since the \hgext{fetch} extension | |
363 is in the standard distribution, Mercurial knows where to search for | |
364 it.) | |
365 | |
365 | 366 %%% Local Variables: |
293
3b1291f24c0d
- replaved latex-mode to yatex-mode
Yoshiki Yazawa <yaz@cc.rim.or.jp>
parents:
290
diff
changeset
|
367 %%% mode: yatex |
84 | 368 %%% TeX-master: "00book" |
365 | 369 %%% End: |