view ja/branch.tex @ 800:1a30d2627512

Propagate 2ff0a43f1152 Update ch03

%\chapter{Managing releases and branchy development}
\chapter{$B%j%j!<%9$H%V%i%s%A3+H/$N4IM}(B}
\label{chap:branch}

%Mercurial provides several mechanisms for you to manage a project that
%is making progress on multiple fronts at once.  To understand these
%mechanisms, let's first take a brief look at a fairly normal software
%project structure.

Mercurial$B$OF1;~$KJ#?t$N6ILL$G?J9T$7$F$$$/%W%m%8%'%/%H$r4IM}$9$k$N$KLrN)(B
$B$D5!G=$r;}$C$F$$$k!%$3$l$i$N5!G=$rM}2r$9$k$?$a!$$^$:DL>o$N%=%U%H%&%'%"%W(B
$B%m%8%'%/%H$N9=B$$r9M$($k!%(B

%Many software projects issue periodic ``major'' releases that contain
%substantial new features.  In parallel, they may issue ``minor''
%releases.  These are usually identical to the major releases off which
%they're based, but with a few bugs fixed.

$BB?$/$N%=%U%H%&%'%"%W%m%8%'%/%H$G$O!$?75!G=$r;}$D%a%8%c!<%j%j!<%9$rDj4|E*(B
$B$K%j%j!<%9$9$k!%JB9T$7$FB??t$N%^%$%J!<%j%j!<%9$b9T$J$o$l$k!%$3$l$i$O%a(B
$B%8%c!<%j%j!<%9$N%P%0$r=$@5$7$?$b$N$G$"$k!%(B

%In this chapter, we'll start by talking about how to keep records of
%project milestones such as releases.  We'll then continue on to talk
%about the flow of work between different phases of a project, and how
%Mercurial can help you to isolate and manage this work.

$B$3$N>O$G$O$^$:%j%j!<%9$N$h$&$J%W%m%8%'%/%H$N%^%$%k%9%H!<%s$K8@5Z$9$k!%<!$$(B
$B$G%W%m%8%'%/%H$N3F%U%'!<%:$G$NN.$l$r@bL@$7!$(BMercurial$B$G$I$N$h$&$K6hJ,$1(B
$B$7!$4IM}$G$-$k$N$+$r@bL@$9$k!%(B

%\section{Giving a persistent name to a revision}
\section{$B%j%S%8%g%s$K1JB3E*$JL>A0$rIU$1$k(B}

%Once you decide that you'd like to call a particular revision a
%``release'', it's a good idea to record the identity of that revision.
%This will let you reproduce that release at a later date, for whatever
%purpose you might need at the time (reproducing a bug, porting to a
%new platform, etc).
%\interaction{tag.init}

$B$"$k%j%S%8%g%s$r%j%j!<%9$H7h$a$?;~$K!$$3$l$r5-O?$7$F$*$/$N$ONI$$9M$($G$"(B
$B$k!%$3$l$O8eF|!$%P%0$N:F8=$d%=%U%H%&%'%"$N0\?"$J$I$NL\E*$G%j%j!<%9$r:F8=(B
$B$9$k$N$KLrN)$D!%(B
\interaction{tag.init}

%Mercurial lets you give a permanent name to any revision using the
%\hgcmd{tag} command.  Not surprisingly, these names are called
%``tags''.
%\interaction{tag.tag}

$BFCDj$N%j%S%8%g%s$K(BMercurial$B$G1JB3E*$JL>A0$rIU$1$k$3$H$,$G$-$k!%$3$NL>A0(B
$B$O%?%0$H8F$P$l$k!%(B
\interaction{tag.tag}

%A tag is nothing more than a ``symbolic name'' for a revision.  Tags
%exist purely for your convenience, so that you have a handy permanent
%way to refer to a revision; Mercurial doesn't interpret the tag names
%you use in any way.
%Neither does Mercurial place any restrictions on
%the name of a tag, beyond a few that are necessary to ensure that a
%tag can be parsed unambiguously.  A tag name cannot contain any of the
%following characters:
%\begin{itemize}
%\item Colon (ASCII 58, ``\texttt{:}'')
%\item Carriage return (ASCII 13, ``\Verb+\r+'')
%\item Newline (ASCII 10, ``\Verb+\n+'')
%\end{itemize}

$B%?%0$O<B$N$H$3$m%j%S%8%g%s$KIU$1$i$l$?%7%s%\%j%C%/%M!<%`$KB>$J$i$J$$!%%?(B
$B%0$OC1$K%f!<%6$NJX59$N$?$a$KIU$1$i$l$k!%%?%0$OFCDj$N%j%S%8%g%s$r;2>H$9$k(B
$B$?$a$N<j7Z$G1JB3E*$JJ}K!$G!$(BMercurial$B$O%?%0$rK]Lu$7$J$$!%%?%0$NL>A0$K$O!$(B
$BL@3N$K%Q!<%9$9$k$?$a$N$$$/$D$+$N$b$N0J30$N@)8B$O$J$$!%%?%0%M!<%`$O0J2<$N(B
$BJ8;z$r4^$`$3$H$O$G$-$J$$!%(B
\begin{itemize}
\item $B%3%m%s(B (ASCII 58, ``\texttt{:}'')
\item $BI|5"J8;z(B (ASCII 13, ``\Verb+\r+'')
\item $B2~9TJ8;z(B (ASCII 10, ``\Verb+\n+'')
\end{itemize}


%You can use the \hgcmd{tags} command to display the tags present in
%your repository.  In the output, each tagged revision is identified
%first by its name, then by revision number, and finally by the unique
%hash of the revision.  
%\interaction{tag.tags}
%Notice that \texttt{tip} is listed in the output of \hgcmd{tags}.  The
%\texttt{tip} tag is a special ``floating'' tag, which always
%identifies the newest revision in the repository.

\hgcmd{tags}$B%3%^%s%I$G%j%]%8%H%j$KB8:_$9$k%?%0$rI=<($9$k$3$H$,$G$-$k!%=P(B
$BNO$G$O!$%?%0IU$1$5$l$?%j%S%8%g%s$OL>A0!$%j%S%8%g%sHV9f!$8GM-$N%O%C%7%eCM(B
$B$N=g$K6hJL$5$l$k!%(B
\interaction{tag.tags}
\hgcmd{tags}$B$N=PNO$K(B\texttt{tip}$B$,4^$^$l$F$$$k$3$H$KCm0U!%(B\texttt{tip}$B%?(B
$B%0$O!$%j%]%8%H%j$NCf$G>o$K:G?7$N%j%S%8%g%s$KIU$1$i$l$F$$$kFCJL$J%U%m!<%F%#(B
$B%s%0%?%0$G$"$k!%(B

%In the output of the \hgcmd{tags} command, tags are listed in reverse
%order, by revision number.  This usually means that recent tags are
%listed before older tags.  It also means that \texttt{tip} is always
%going to be the first tag listed in the output of \hgcmd{tags}.

\hgcmd{tags}$B%3%^%s%I$N=PNO$K$*$$$F!$%?%0$O%j%S%8%g%sHV9f$K$h$C$F5U=g$GI=(B
$B<($5$l$F$$$k!%$3$l$K$h$C$F!$DL>o!$?7$7$$%?%0$,8E$$%?%0$h$j$bA0$KI=<($5$l(B
$B$k!%(B\texttt{tip}$B%?%0$O(B\hgcmd{tags}$B%3%^%s%I$N=PNO$N0lHV@hF,$KI=<($5$l$k!%(B

%When you run \hgcmd{log}, if it displays a revision that has tags
%associated with it, it will print those tags.
%\interaction{tag.log}

\hgcmd{log}$B%3%^%s%I$O%?%0$N7k$S$D$1$i$l$?%j%S%8%g%s$rI=<($9$k:]$K%?%0$b(B
$BI=<($9$k!%(B
\interaction{tag.log}

%Any time you need to provide a revision~ID to a Mercurial command, the
%command will accept a tag name in its place.  Internally, Mercurial
%will translate your tag name into the corresponding revision~ID, then
%use that.
%\interaction{tag.log.v1.0}

Mecurial$B%3%^%s%I$K%j%S%8%g%sHV9f$rEO$9I,MW$,$"$k>l9g!$>o$K%?%0%M!<%`$r;H(B
$B$&$3$H$,$G$-$k!%FbItE*$K$O(BMercurial$B$O%?%0%M!<%`$rBP1~$9$k%j%S%8%g%s(BID$B$K(B
$BJQ49$7$F;HMQ$7$F$$$k!%(B
\interaction{tag.log.v1.0}

%There's no limit on the number of tags you can have in a repository, or
%on the number of tags that a single revision can have.  As a practical
%matter, it's not a great idea to have ``too many'' (a number which will
%vary from project to project), simply because tags are supposed to help
%you to find revisions.  If you have lots of tags, the ease of using them
%to identify revisions diminishes rapidly.

$B%j%]%8%H%j$NCf$G;H$($k%?%0?t!$0l$D$N%j%S%8%g%s$KIU$1$i$l$k%?%0?t$K>e8B$O(B
$B$J$$!%;v>p$O%W%m%8%'%/%H$K$h$C$F0[$J$k$@$m$&$,!$<BMQE*$K$O%?%0$rB?$/IU$1(B
$B$9$.$k$3$H$O$"$^$jNI$$9M$($H$O8@$($J$$!%%?%0$H$O%j%S%8%g%s$r8+$D$10W$/$9(B
$B$k$?$a$K;H$&$b$N$@$+$i$@!%%?%0$rB?$/IU$1$9$.$k$H!$%?%0$K$h$C$F%j%S%8%g%s(B
$B$N6hJL$r$9$k$3$H$,$H$?$s$KFq$7$/$J$k!%(B

%For example, if your project has milestones as frequent as every few
%days, it's perfectly reasonable to tag each one of those.  But if you
%have a continuous build system that makes sure every revision can be
%built cleanly, you'd be introducing a lot of noise if you were to tag
%every clean build.  Instead, you could tag failed builds (on the
%assumption that they're rare!), or simply not use tags to track
%buildability.

$BNc$($P$"$J$?$N%W%m%8%'%/%H$,?tF|Kh$K%^%$%k%9%H!<%s$r7^$($F$$$k>l9g!$$=$l(B
$B$>$l$K%?%0$rIU$1$k$3$H$OM}$KE,$C$F$$$k!%$7$+$7!$$=$l$>$l$N%j%S%8%g%s$,%/(B
$B%j!<%s$K%S%k%I$G$-$k$+8!>Z$9$k$?$a$N%S%k%I%7%9%F%`$r;}$C$F$$$k$h$&$J>l9g!$(B
$B$=$l$>$l$N%/%j!<%s%S%k%I$K%?%0$rIU$1$F$$$?$i<}=&$,$D$+$J$/$J$k$@$m$&!%$`(B
$B$7$m%S%k%I$,<:GT$9$k$3$H$,>/$J$$$N$G$"$l$P!$<:GT$7$?%j%S%8%g%s$K%?%0$r$D(B
$B$1$?J}$,NI$$$7!$C1$K%S%k%I$,DL$C$?$3$H$r<($9$N$K%?%0$rMQ$$$k$Y$-$G$O$J$$(B
$B$+$bCN$l$J$$!%(B

%If you want to remove a tag that you no longer want, use
%\hgcmdargs{tag}{--remove}.  
%\interaction{tag.remove}
%You can also modify a tag at any time, so that it identifies a
%different revision, by simply issuing a new \hgcmd{tag} command.
%You'll have to use the \hgopt{tag}{-f} option to tell Mercurial that
%you \emph{really} want to update the tag.
%\interaction{tag.replace}
%There will still be a permanent record of the previous identity of the
%tag, but Mercurial will no longer use it.  There's thus no penalty to
%tagging the wrong revision; all you have to do is turn around and tag
%the correct revision once you discover your error.

$B%?%0$,I,MW$J$/$J$C$?;~$O(B\hgcmdargs{tag}{--remove}$B%3%^%s%I$G>C$9$3$H$,$G(B
$B$-$k!%(B
\interaction{tag.remove}
$B%?%0$O$$$D$G$bJQ99$G$-$k$N$G!$$"$k%?%0$rB>$N%j%S%8%g%s$KIU$1BX$($k$h$&$J(B
$B$3$H$b$G$-$k!%(B
$B%?%0$r(B\emph{$BK\Ev(B}$B$K99?7$7$?$$>l9g$O(B\hgopt{tag}{-f}$B%*%W%7%g%s$r;XDj$9$kI,(B
$BMW$,$"$k!%(B
\interaction{tag.replace}
$B%?%0$N0JA0$N%"%$%G%s%F%#%F%#!<$N1JB3E*$J5-O?$O;D$C$F$$$k$,!$(BMercurial$B$O$b(B
$B$O$d$3$l$rMxMQ$7$J$$!%$h$C$F!$4V0c$C$?%j%S%8%g%s$K%?%0$rIU$1$k$3$H$G%Z%J(B
$B%k%F%#$,2]$;$i$l$k$H$$$&$3$H$O$J$$!%4V0c$$$r8+$D$1$?;~$OC1$K$d$jD>$7$F@5(B
$B$7$$%j%S%8%g%s$K%?%0$rIU$1$l$P$h$$!%(B

%Mercurial stores tags in a normal revision-controlled file in your
%repository.If you've created any tags, you'll find them in a file
%named \sfilename{.hgtags}.When you run the \hgcmd{tag} command,
%Mercurial modifies this file, then automatically commits the change to
%it.This means that every time you run \hgcmd{tag}, you'll see a
%corresponding changeset in the output of \hgcmd{log}.
%\interaction{tag.tip}

Mercurial$B$O%?%0$r%j%]%8%H%j$NCf$NDL>o$N%j%S%8%g%s4IM}%U%!%$%k$KJ]B8$9$k!%(B
$B%?%0$r:n@.$7$?;~!$(B\sfilename{.hgtags}$B$H$$$&%U%!%$%k$K%?%0$,J]B8$5$l$F$$(B
$B$k$N$,J,$+$k$@$m$&!%(B\hgcmd{tag}$B%3%^%s%I$r<B9T$9$k$H(BMercurial$B$O$3$N%U%!%$(B
$B%k$rJQ99$7!$JQ99$r$3$N%U%!%$%k$K%3%_%C%H$9$k!%$D$^$j(B\hgcmd{tag}$B$r<B9T$9(B
$B$k$H$$$D$b(B\hgcmd{log}$B$N=PNO$NCf$KBP1~$9$k%A%'%s%8%;%C%H$r8+$k$3$H$K$J$k!%(B
\interaction{tag.tip}

%\subsection{Handling tag conflicts during a merge}
\subsection{$B%^!<%8$N:]$K%?%0$N%3%s%U%j%/%H$r2r7h$9$k(B}

%You won't often need to care about the \sfilename{.hgtags} file, but
%it sometimes makes its presence known during a merge.  The format of
%the file is simple: it consists of a series of lines.  Each line
%starts with a changeset hash, followed by a space, followed by the
%name of a tag.

\sfilename{.hgtags}$B$r5$$K$7$J$1$l$P$J$i$J$$$3$H$OB?$/$J$$$,!$%^!<%8$N:]$K(B
$B$OB8:_$rL@$i$+$K$9$k!%%U%!%$%k%U%)!<%^%C%H$O%7%s%W%k$G!$0lO"$N9T$r4^$`$@(B
$B$1$G$"$k!%$=$l$>$l$N9T$O%A%'%s%8%;%C%H$N%O%C%7%e$G;O$^$j!$(B1$B$D$N%9%Z!<%9(B
$B$,B3$-!$%?%0$NL>>N$,B3$/!%(B

%If you're resolving a conflict in the \sfilename{.hgtags} file during
%a merge, there's one twist to modifying the \sfilename{.hgtags} file:
%when Mercurial is parsing the tags in a repository, it \emph{never}
%reads the working copy of the \sfilename{.hgtags} file.  Instead, it
%reads the \emph{most recently committed} revision of the file.

$B%^!<%8Cf$K(B\sfilename{.hgtags}$B%U%!%$%kFb$N%3%s%U%j%/%H$r2r7h$7$F$$$k>l9g!$(B
\sfilename{.hgtags}$B$rJQ99$9$k0lG1$j$,$"$k!%(BMercurial$B$,%j%]%8%H%jCf$N%?%0(B
$B$r%Q!<%9$9$k;~!$(BMercurial$B$O(B\sfilename{.hgtags}$B$N%o!<%-%s%0%3%T!<$r(B
\emph{$B7h$7$F(B}$BFI$^$J$$!%$=$NBe$o$j(B\emph{$B:G$b?7$7$/%3%_%C%H$5$l$?(B}$B%j%S%8%g(B
$B%s$rFI$`!%(B

%An unfortunate consequence of this design is that you can't actually
%verify that your merged \sfilename{.hgtags} file is correct until
%\emph{after} you've committed a change.  So if you find yourself
%resolving a conflict on \sfilename{.hgtags} during a merge, be sure to
%run \hgcmd{tags} after you commit.If it finds an error in the
%\sfilename{.hgtags} file, it will report the location of the error,
%which you can then fix and commit.  You should then run \hgcmd{tags}
%again, just to be sure that your fix is correct.

$B$3$N@_7W$N;DG0$J7k2L$O!$JQ99$r%3%_%C%H$7$?(B\emph{$B8e(B}$B$G$J$$$H%^!<%8$7$?(B
\sfilename{.hgtags}$B%U%!%$%k$r<B:]$K$O%Y%j%U%!%$$G$-$J$$$3$H$G$"$k!%$=$N$?(B
$B$a!$%^!<%8Cf$K(B\sfilename{.hgtags}$B$N%3%s%U%j%/%H2r7h$r$7$F$$$k>l9g$O!$%3%_%C(B
$B%H8e$KK:$l$:(B\hgcmd{tags}$B$r<B9T$9$kI,MW$,$"$k!%(B\sfilename{.hgtags}$B$K%(%i!<(B
$B$,8+$D$+$C$?>l9g!$%(%i!<$N$"$k>l=j$rJs9p$9$k!%$=$l$r8+$F=$@5$7!$%3%_%C%H(B
$B$9$k$3$H$,$G$-$k!%$=$3$G(B\hgcmd{tags}$B$r:F$SAv$i$;!$=$@5$,@5$7$$$3$H$r3NG'(B
$B$9$Y$-$G$"$k!%(B


%\subsection{Tags and cloning}
\subsection{$B%?%0$H%/%m!<%s(B}

%You may have noticed that the \hgcmd{clone} command has a
%\hgopt{clone}{-r} option that lets you clone an exact copy of the
%repository as of a particular changeset.The new clone will not contain
%any project history that comes after the revision you specified.  This
%has an interaction with tags that can surprise the unwary.

\hgcmd{clone}$B%3%^%s%I$,(B\hgopt{clone}{-r}$B%*%W%7%g%s$r;}$C$F$$$k$3$H$K$9$G(B
$B$K5$$E$$$F$$$k$+$bCN$l$J$$!%$3$N%*%W%7%g%s$GFCDj$N%A%'%s%8%;%C%H$N%3%T!<(B
$B$r%/%m!<%s$9$k$3$H$,$G$-$k$,!"%/%m!<%s$7$?%3%T!<$O!$;XDj$7$?%j%S%8%g%s8e(B
$B$NMzNr$r;}$?$J$$$?$a!"ITMQ?4$J%f!<%6$O$7$P$7$P6C$/$3$H$K$J$k!#(B

%Recall that a tag is stored as a revision to the \sfilename{.hgtags}
%file, so that when you create a tag, the changeset in which it's
%recorded necessarily refers to an older changeset.
%When you run \hgcmdargs{clone}{-r foo} to clone a repository as of tag
%\texttt{foo}, the new clone \emph{will not contain the history that
%created the tag} that you used to clone the repository.
%The resultis that you'll get exactly the right subset of the project's
%history in the new repository, but \emph{not} the tag you might have
%expected.

$B%?%0$O(B\sfilename{.hgtags}$B%U%!%$%kFb$N%j%S%8%g%s$H$7$F5-O?$5$l$F$$$k$3$H$r(B
$B;W$$=P$7$FM_$7$$!%$3$N$?$a!$%?%0:n@.;~$K!$%?%0$,5-O?$5$l$F$$$k%A%'%s%8%;%C(B
$B%H$+$i8E$$%A%'%s%8%;%C%H$X$N;2>H$,@8$8$k!%%?%0(B\texttt{foo}$B$,IU$$$F$$$k%j(B
$B%]%8%H%j$r%/%m!<%s$9$k$?$a$K(B\hgcmdargs{clone}{-r foo}$B<B9T$9$k;~!$?7$7$$%/(B
$B%m!<%s$O%?%0$r@8@.$7$?MzNr$r(B\emph{$B4^$^$J$$(B}$B!%7k2L$H$7$F!$?7$7$$%j%]%8%H%j(B
$B$K4^$^$l$kMzNr$O!$%W%m%8%'%/%HMzNr$N%5%V%;%C%H$K$J$j!$%?%0$O4^$^$l$J$$!%(B


%\subsection{When permanent tags are too much}
\subsection{$B1J5W%?%0$,I,MW$G$J$$>l9g(B}

%Since Mercurial's tags are revision controlled and carried around with
%a project's history, everyone you work with will see the tags you
%create.  But giving names to revisions has uses beyond simply noting
%that revision \texttt{4237e45506ee} is really \texttt{v2.0.2}.  If
%you're trying to track down a subtle bug, you might want a tag to
%remind you of something like ``Anne saw the symptoms with this
%revision''.

Mercurial$B$N%?%0$O%j%S%8%g%s%3%s%H%m!<%k$5$l!$%W%m%8%'%/%HMzNr$KIU?o$7$F$$(B
$B$k$?$a!$F1$8%W%m%8%'%/%H$GF/$/?M$O3'%?%0$rCN$k$3$H$K$J$k!%%j%S%8%g%s$KL>(B
$BA0$rIU$1$k$3$H$O!$C1$K%j%S%8%g%s(B\texttt{4237e45506ee}$B$,%P!<%8%g%s(B
\texttt{v2.0.2}$B$G$"$k$H5-=R$9$k0J>e$N0UL#$r;}$D!%$b$7%P%0$rDI@W$7$F$$$k$J(B
$B$i!$(B``Anne saw the symptoms with this revision''$B!J%"%s$O$3$N%j%S%8%g%s$G(B
$B>I>u$r8+$?!K$J$I$N%?%0$rIU$1$?$/$J$k$@$m$&!%(B

%For cases like this, what you might want to use are \emph{local} tags.
%You can create a local tag with the \hgopt{tag}{-l} option to the
%\hgcmd{tag} command. This will store the tag in a file called
%\sfilename{.hg/localtags}.  Unlike \sfilename{.hgtags},
%\sfilename{.hg/localtags} is not revision controlled.  Any tags you
%create using \hgopt{tag}{-l} remain strictly local to the repository
%you're currently working in.

$B$3$N$h$&$J>l9g!$(B\emph{$B%m!<%+%k(B}$B%?%0$r;H$$$?$/$J$k$O$:$@!%%m!<%+%k%?%0$O(B
\hgcmd{tag}$B%3%^%s%I$r(B\hgopt{tag}{-l}$B%*%W%7%g%sIU$-$G;H$&$3$H$G:n@.$G$-$k!%(B
$B$3$N%*%W%7%g%s$r;H$&$H!$%?%0$O(B\sfilename{.hg/localtags}$B$H$$$&%U%!%$%k$KJ](B
$BB8$5$l$k!%(B\sfilename{.hgtags}$B$H0c$C$F!$(B\sfilename{.hg/localtags}$B$O%j%S%8%g(B
$B%s%3%s%H%m!<%k$5$l$J$$!%(B\hgopt{tag}{-l}$B%*%W%7%g%s$G:n@.$7$?$"$i$f$k%?%0(B
$B$O87L)$K%m!<%+%k$K4IM}$5$l!$:#:n6H$7$F$$$k$m%]%8<h$j$K$O0l@ZH?1G$5$l$J$$!%(B


%\section{The flow of changes---big picture vs. little}
\section{$B99?7$NN.$l(B---$BBg6IE*(B vs.$B6I=jE*(B}

%To return to the outline I sketched at the beginning of a chapter,
%let's think about a project that has multiple concurrent pieces of
%work under development at once.

$B$3$N>O$N:G=i$G<($7$?%"%&%H%i%$%s$KLa$k$?$a$K!$%W%m%8%'%/%H$,3+H/Cf!$0lEY(B
$B$KJ#?t$NJB9T$7$?ItJ,$r;}$D$H9M$($h$&!%(B

%There might be a push for a new ``main'' release; a new minor bugfix
%release to the last main release; and an unexpected ``hot fix'' to an
%old release that is now in maintenance mode.

$B?7$7$$(B``main''$B$r%j%j!<%9$9$k>u67$G!$:G?7$N%a%$%s%j%j!<%9$KBP$9$k?7$7$$>.(B
$B5,LO$J%P%0%U%#%C%/%9%j%j!<%9$H4{$K%a%s%F%J%s%9%b!<%I$K$J$C$F$$$k8E$$%j%j!<(B
$B%98~$1$NM=4|$;$L(B``hot fix'' $B$r%j%j!<%9$9$k>u67$r9M$($k!%(B


%The usual way people refer to these different concurrent directions of
%development is as ``branches''.  However, we've already seen numerous
%times that Mercurial treats \emph{all of history} as a series of
%branches and merges.  Really, what we have here is two ideas that are
%peripherally related, but which happen to share a name.
%\begin{itemize}
%\item ``Big picture'' branches represent the sweep of a project's
%  evolution; people give them names, and talk about them in
%  conversation.
%\item ``Little picture'' branches are artefacts of the day-to-day
%  activity of developing and merging changes.  They expose the
%  narrative of how the code was developed.
%\end{itemize}

$B?M!9$,!$0[$J$C$?JB9TE*$J3+H/$NJ}8~@-$K$D$$$F?($l$k;~$O!$(B``$B%V%i%s%A(B''$B$H$7(B
$B$F8@5Z$9$k!%$7$+$7!$4{$K4vEY$H$J$/(BMercurial$B$,(B\emph{$BA4$F$NMzNr(B}$B$r0lO"$N%V(B
$B%i%s%A$H%^!<%8$H$7$F<h$j07$C$F$$$k$N$r8+$F$-$?!%$3$3$G$O!$$o$:$+$K4XO"$7(B
$B$F$$$k$,L>A0$r6&M-$7$F$$$k(B2$B$D$N%"%$%G%#%"$r9M$($k!%(B
\begin{itemize}
\item ``Big picture''$B%V%i%s%A$O%W%m%8%'%/%H$N?J2=$rI=$9!%3+H/<T$O$3$l$i(B
      $B$KL>A0$rM?$(!$2qOC$GMQ$$$k!%(B
\item ``Little picture''$B%V%i%s%A$OF|!9$N3+H/$H%^!<%8$N=j;:$G!$%3!<%I$,$I(B
      $B$N$h$&$K3+H/$5$l$?$+$r<($9$b$N$G$"$k!%(B
\end{itemize}

%\section{Managing big-picture branches in repositories}
\section{$B%j%]%8%H%j4V$G$NBg6IE*%V%i%s%A$N4IM}(B}

%The easiest way to isolate a ``big picture'' branch in Mercurial is in
%a dedicated repository.  If you have an existing shared
%repository---let's call it \texttt{myproject}---that reaches a ``1.0''
%milestone, you can start to prepare for future maintenance releases on
%top of version~1.0 by tagging the revision from which you prepared
%the~1.0 release.
%\interaction{branch-repo.tag}
%You can then clone a new shared \texttt{myproject-1.0.1} repository as
%of that tag.
%\interaction{branch-repo.clone}

Mercurial$B$G(B``bit picture''$B$r3VN%$9$k:G$b4JC1$JJ}K!$O!$@lMQ$N%j%]%8%H%j$r(B
$BMQ0U$9$k$3$H$G$"$k!%$b$70l$D$N6&M-%j%]%8%H%j$r;}$C$F$$$k>l9g!$$3$l$r(B
\texttt{myproject}$B$H8F$V$3$H$K$7$k!%$3$l$,(B``1.0''$B%^%$%k%9%H!<%s$KE~C#$7$?(B
$B$i!$(B1.0$B$K(B1.0$B%j%j!<%9$H%?%0$rIU$1!$>-Mh$N%a%s%F%J%s%9%j%j!<%9$KHw$($k$3$H(B
$B$,$G$-$k!%(B
\interaction{branch-repo.tag}
$B$=$7$F?7$?$K(B\texttt{myproject-1.0.1}$B$H%?%0$rIU$1$F%j%]%8%H%j$r%/%m!<%s$9(B
$B$k!%(B
\interaction{branch-repo.clone}

%Afterwards, if someone needs to work on a bug fix that ought to go
%into an upcoming~1.0.1 minor release, they clone the
%\texttt{myproject-1.0.1} repository, make their changes, and push them
%back.
%\interaction{branch-repo.bugfix}
%Meanwhile, development for the next major release can continue,
%isolated and unabated, in the \texttt{myproject} repository.
%\interaction{branch-repo.new}

$B0J8e!$%P%0%U%#%C%/%9$r$7$?$$?M$O(B1.0.1$B%^%$%J!<%j%j!<%9$X$$$/$Y$-$G$"$k!%(B
$BH`$i$O(B\texttt{myproject-1.0.1}$B%j%]%8%H%j$r%/%m!<%s$7!$JQ99$r2C$(!$%W%C%7%e(B
$B$9$k!%(B
\interaction{branch-repo.bugfix}
$B0lJ}$G<!$N%a%8%c!<%j%j!<%9$K8~$1$F$N3+H/$O!$(B\texttt{myproject}$B%j%]%8%H%j(B
$B$NCf$G3VN%$5$l!$BZ$k;v$J$/7QB3$9$k$3$H$,2DG=$G$"$k!%(B
\interaction{branch-repo.new}

%\section{Don't repeat yourself: merging across branches}
\section{$B<j$G7+$jJV$5$J$$$3$H!'%V%i%s%A4V$G$N%^!<%8(B}

%In many cases, if you have a bug to fix on a maintenance branch, the
%chances are good that the bug exists on your project's main branch
%(and possibly other maintenance branches, too).  It's a rare developer
%who wants to fix the same bug multiple times, so let's look at a few
%ways that Mercurial can help you to manage these bugfixes without
%duplicating your work.

$B%a%s%F%J%s%9%V%i%s%A$G=$@5$9$Y$-%P%0$,$"$k$H$-!$B?$/$N>l9g!$%a%$%s%V%i%s(B
$B%A$K$=$N%P%0$,$"$k2DG=@-$O9b$$!%!J$5$i$KB>$N%a%s%F%J%s%9%V%i%s%A$K$*$$$F(B
$B$b!%!K%P%0$N=$@5$r2?EY$b7+$jJV$7$?$$$H;W$&3+H/<T$O$^$:$$$J$$!%$=$3$G%P%0(B
$B=$@5$r7+$jJV$9Be$o$j$N$G$O$J$/!$(BMercurial$B$G2r7h$G$-$k$$$/$D$+$NJ}K!$r8+(B
$B$F$_$k$3$H$K$7$h$&!%(B

%In the simplest instance, all you need to do is pull changes from your
%maintenance branch into your local clone of the target branch.
%\interaction{branch-repo.pull}
%You'll then need to merge the heads of the two branches, and push back
%to the main branch.
%\interaction{branch-repo.merge}

$B:G$b4JC1$J$N$O!$%a%s%F%J%s%9%V%i%s%A$+$iJQ99$r%?!<%2%C%H%V%i%s%A$N%m!<%+(B
$B%k%/%m!<%s$K(Bpull$B$9$kJ}K!$G$"$k!%(B
\interaction{branch-repo.pull}
$B$=$N8e(B2$B$D$N%V%i%s%A$N%X%C%IF1;N$r%^!<%8$7!$%a%$%s%V%i%s%A$X%W%C%7%e$9$k!%(B
\interaction{branch-repo.merge}

%\section{Naming branches within one repository}
\section{1$B$D$N%j%]%8%H%jFb$G$N%V%i%s%A$NL?L>(B}

%In most instances, isolating branches in repositories is the right
%approach.  Its simplicity makes it easy to understand; and so it's
%hard to make mistakes.  There's a one-to-one relationship between
%branches you're working in and directories on your system.  This lets
%you use normal (non-Mercurial-aware) tools to work on files within a
%branch/repository.

$BB?$/$N>l9g!$%V%i%s%AKh$KJ#?t$N%j%]%8%H%j$rMQ0U$73VN%$9$k$N$O@5$7$$%"%W%m!<(B
$B%A$G$"$k!%$3$l$OC1=c$J$?$aGD0.$,MF0W$G$"$j!$<:GT$rHH$92DG=@-$,Dc$$!%:n6H(B
$B$7$F$$$k%V%i%s%A$H%G%#%l%/%H%j$N4V$K$O(B1$BBP(B1$B$N4X78$,$"$k!%(BMercurial$B$r9MN8$7(B
$B$J$$DL>o$N%D!<%k$r%V%i%s%A!?%j%]%8%H%jFb$N%U%!%$%k$KBg$7$F;H$&$3$H$b2DG=(B
$B$G$"$k!%(B

%If you're more in the ``power user'' category (\emph{and} your
%collaborators are too), there is an alternative way of handling
%branches that you can consider.  I've already mentioned the
%human-level distinction between ``small picture'' and ``big picture''
%branches.  While Mercurial works with multiple ``small picture''
%branches in a repository all the time (for example after you pull
%changes in, but before you merge them), it can \emph{also} work with
%multiple ``big picture'' branches.

$B$"$J$?$H!J$"$J$?$N6(NO<T$,(B\emph{$B6&$K(B}$B!K(B``$B%Q%o!<%f!<%6(B''$B0J>e$N%+%F%4%j$KB0(B
$B$9$J$i!$%V%i%s%A$r<h$j07$&JL$NJ}K!$b9M$($i$l$k!%$9$G$K(B``$B6I=jE*$J%b%G%k(B''
$B$H(B``$BBg6IE*$J%b%G%k(B''$B$H$$$&!$6hJL$K$D$$$F?($l$?!%(BMercurial$B$O!$J#?t$N(B``$B6I=j(B
$BE*$J(B''$B%V%i%s%A!J$?$H$($PJQ99$r(Bpull$B$7$F%^!<%8$7$F$$$J$$>l9g$J$I!KMQ$$$k$3(B
$B$H$,$G$-$k0lJ}$G!$J#?t$N(B``$BBg6IE*$J(B''$B%V%i%s%A$rMQ$$$k$3$H(B\emph{$B$b(B}$B$G$-$k!%(B

%The key to working this way is that Mercurial lets you assign a
%persistent \emph{name} to a branch.  There always exists a branch
%named \texttt{default}.  Even before you start naming branches
%yourself, you can find traces of the \texttt{default} branch if you
%look for them.

$B$3$NJ}K!$rMQ$$$k:]$N80$O!$(BMercurial$B$K$h$C$F%V%i%s%A$K1JB3E*$J(B\emph{$BL>A0(B}
$B$rIU$1$k$3$H$G$"$k!%%V%i%s%A$KL>A0$rIU$1$kA0$G$b!$(B\texttt{default}$B%V%i%s(B
$B%A$N%H%l!<%9$r8+$k$3$H$,$G$-$k!%(B

%As an example, when you run the \hgcmd{commit} command, and it pops up
%your editor so that you can enter a commit message, look for a line
%that contains the text ``\texttt{HG: branch default}'' at the bottom.
%This is telling you that your commit will occur on the branch named
%\texttt{default}.

$BNc$H$7$F!$(B\hgcmd{commit}$B%3%^%s%I$r<B9T$7!$%3%_%C%H%a%C%;!<%8$r=q$/$?$a$K(B
$B%(%G%#%?$,5/F0$5$l$?;~!$:G2<It$N(B``\texttt{HG: branch default}''$B$H$$$&9T(B
$B$r8+$F$[$7$$!%$3$N9T$O%3%_%C%H$,(B\texttt{default}$B$H$$$&L>A0$N%V%i%s%A$KBP(B
$B$7$F9T$o$l$k$3$H$r<($7$F$$$k!%(B

%To start working with named branches, use the \hgcmd{branches}
%command.  This command lists the named branches already present in
%your repository, telling you which changeset is the tip of each.
%\interaction{branch-named.branches}
%Since you haven't created any named branches yet, the only one that
%exists is \texttt{default}.

$BL>A0IU$-%V%i%s%A$r;H$&$K$"$?$C$F!$$^$:(B\hgcmd{branches}$B$r;H$$!$%j%]%8%H%j(B
$BFb$K$9$G$KB8:_$9$kL>A0IU$-%V%i%s%A$rNs5s$9$k$3$H$+$i;O$a$k!%$3$N%3%^%s%I(B
$B$K$h$C$F$=$l$>$l$N%V%i%s%A$N(Btip$B$K$J$C$F$$$k%A%'%s%8%;%C%H$,$o$+$k!%(B
\interaction{branch-named.branches}
$B$3$3$G$O$^$@L>A0IU$-%V%i%s%A$r:n$C$F$$$J$$$N$G!$(B\texttt{default}$B%V%i%s%A(B
$B$@$1$,B8:_$9$k!%(B

%To find out what the ``current'' branch is, run the \hgcmd{branch}
%command, giving it no arguments.  This tells you what branch the
%parent of the current changeset is on.
%\interaction{branch-named.branch}

$B8=:_$N%V%i%s%A$,2?$J$N$+$rCN$k$?$a$K$O!$(B\hgcmd{branch}$B%3%^%s%I$r0z?t$J$7(B
$B$G<B9T$9$k!%$3$N%3%^%s%I$G8=:_$N%A%'%s%8%;%C%H$N?F%V%i%s%A$,$o$+$k!%(B
\interaction{branch-named.branch}

%To create a new branch, run the \hgcmd{branch} command again.  This
%time, give it one argument: the name of the branch you want to create.
%\interaction{branch-named.create}

$B?7$7$$%V%i%s%A$r:n$k$N$K$b(B\hgcmd{branch}$B%3%^%s%I$r;H$&!%$3$N>l9g$O!$:n@.(B
$B$7$?$$%V%i%s%A$NL>A0$r0z?t$H$7$FEO$9!%(B
\interaction{branch-named.create}

%After you've created a branch, you might wonder what effect the
%\hgcmd{branch} command has had.  What do the \hgcmd{status} and
%\hgcmd{tip} commands report?
%\interaction{branch-named.status}
%Nothing has changed in the working directory, and there's been no new
%history created.  As this suggests, running the \hgcmd{branch} command
%has no permanent effect; it only tells Mercurial what branch name to
%use the \emph{next} time you commit a changeset.

$B%V%i%s%A$r:n$C$?8e$G(B\hgcmd{branch}$B%3%^%s%I$,$I$N$h$&$J8z2L$r;}$C$F$$$k$N(B
$B$+J,$+$i$J$$$+$b$7$l$J$$!%(B\hgcmd{status}$B%3%^%s%I$H(B\hgcmd{tip}$B%3%^%s%I$O(B
$B$=$l$>$l2?$rI=<($9$k$@$m$&$+!)(B
\interaction{branch-named.status}
$B%o!<%-%s%0%G%#%l%/%H%jFb$G$O2?$bJQ2=$O5/$-$:!$2?$N%R%9%H%j$b@8@.$5$l$F$$(B
$B$J$$!%$3$l$+$iJ,$+$k$h$&$K!$(B\hgcmd{branch}$B%3%^%s%I$r<B9T$7$F$b!$1JB3E*$J(B
$B8z2L$O2?$b5/$-$J$$!%$3$N%3%^%s%I$O(B\emph{$B<!$N(B}$B%A%'%s%8%;%C%H$N%3%_%C%H$,(B
$B$I$N%V%i%s%A$KBP$7$F9T$o$l$k$+$r(BMercurial$B%3%^%s%I$K<($9$N$K;H$o$l$k!%(B

%When you commit a change, Mercurial records the name of the branch on
%which you committed.  Once you've switched from the \texttt{default}
%branch to another and committed, you'll see the name of the new branch
%show up in the output of \hgcmd{log}, \hgcmd{tip}, and other commands
%that display the same kind of output.
%\interaction{branch-named.commit}
%The \hgcmd{log}-like commands will print the branch name of every
%changeset that's not on the \texttt{default} branch.  As a result, if
%you never use named branches, you'll never see this information.

$BJQ99$r%3%_%C%H$9$k;~!$(BMercurial$B$O%3%_%C%H$9$k$NBP>]$K$J$k%V%i%s%A$NL>A0(B
$B$r5-O?$9$k!%$R$H$?$S(B\texttt{default}$B$+$iB>$XJQ99$9$l$P!$?7$7$$%V%i%s%AL>(B
$B$,(B\hgcmd{log}$B$d(B\hgcmd{tip}$B$N=PNO$K4^$^$l$k$N$,8+$F<h$l$k$@$m$&!%(B
\interaction{branch-named.commit}
\hgcmd{log}$B$N$h$&$J%3%^%s%I$O!$(B\texttt{default}$B%V%i%s%A0J30$KB0$9$k$9$Y$F(B
$B$N%A%'%s%8%;%C%H$KBP$7$F%V%i%s%AL>$rI=<($9$k!%%V%i%s%A$KL>A0$rIU$1$F$$$J(B
$B$$>l9g$O$3$N=PNO$rL\$K$9$k$3$H$O$J$$!%(B

%Once you've named a branch and committed a change with that name,
%every subsequent commit that descends from that change will inherit
%the same branch name.  You can change the name of a branch at any
%time, using the \hgcmd{branch} command.  
%\interaction{branch-named.rebranch}
%In practice, this is something you won't do very often, as branch
%names tend to have fairly long lifetimes.  (This isn't a rule, just an
%observation.)

$B%V%i%s%A$KL>A0$rIU$1!$$=$NL>A0$r;H$C$FJQ99$N%3%_%C%H$r9T$&$H!$0J8e$KB3$/(B
$BA4$F$N%3%_%C%H$OF1$8L>A0$r;}$D!%L>A0$NJQ99$O(B\hgcmd{branch}$B%3%^%s%I$r;H$&$3(B
$B$H$G$O$$$D$G$b2DG=$@!%(B
\interaction{branch-named.rebranch}
$B<BMQ$K$*$$$F$O!$%V%i%s%AL>$O$+$J$jD9$$4|4V;H$o$l$k798~$,$"$j!$JQ99$OIQHK(B
$B$K$O9T$o$l$J$$!%!J$3$l$OK!B'$H8@$($k$h$&$J$b$N$G$O$J$/!$C1$J$k4QB,7k2L$G(B
$B$"$k!%!K(B

%\section{Dealing with multiple named branches in a repository}
\section{$B%j%]%8%H%jFb$GJ#?t$NL>A0$NIU$$$?%V%i%s%A$N<h$j07$$(B}

%If you have more than one named branch in a repository, Mercurial will
%remember the branch that your working directory on when you start a
%command like \hgcmd{update} or \hgcmdargs{pull}{-u}.  It will update
%the working directory to the tip of this branch, no matter what the
%``repo-wide'' tip is.  To update to a revision that's on a different
%named branch, you may need to use the \hgopt{update}{-C} option to
%\hgcmd{update}.

1$B$D$N%j%]%8%H%jFb$K(B2$B$D0J>e$N%V%i%s%A$r;}$C$F$$$k>l9g!$(BMercurial$B$O!$(B
\hgcmd{update}$B$d(B\hgcmdargs{pull}{-u}$B$N$h$&$J%3%^%s%I$rN)$A>e$2$k$H$-$K!$(B
$B%o!<%-%s%0%G%#%l%/%H%j$,$I$N%V%i%s%A$G$"$k$+5-21$7$F$$$k!%(B
$B$3$l$i$N%3%^%s%I$O!$%j%]%8%H%jA4BN$G$N(Btip$B$,2?$G$"$k$+$K$O4X78$J$/!$%o!<%-(B
$B%s%0%G%#%l%/%H%j$r8=:_$N%V%i%s%A$N(Btip$B$K99?7$9$k!%(B
$BB>$NL>A0$D$-%V%i%s%A$KB0$9%j%S%8%g%s$X99?7$9$k$K$O!$(B\hgopt{update}{-C}$B%*(B
$B%W%7%g%sIU$-$G(B\hgcmd{update}$B%3%^%s%I$r<B9T$9$kI,MW$,$"$k$+$b$7$l$J$$!%(B

%This behaviour is a little subtle, so let's see it in action.  First,
%let's remind ourselves what branch we're currently on, and what
%branches are in our repository.
%\interaction{branch-named.parents}
%We're on the \texttt{bar} branch, but there also exists an older
%\texttt{foo} branch.

$B$3$N$U$k$^$$$O$d$d4q0[$+$b$7$l$J$$!%<B:]$NF0:n$r8+$F$_$k$3$H$K$9$k!%$^$:(B
$B2f!9$,$I$N%V%i%s%A$K$$$k$+$rD4$Y!$%j%]%8%H%j$K$I$s$J%V%i%s%A$,$"$k$+8+$F(B
$B$_$h$&!%(B
\interaction{branch-named.parents}
$B:#$$$k$N$O(B\texttt{bar}$B%V%i%s%A$G!$(B\texttt{foo}$B%V%i%s%A$bB8:_$9$k!%(B

%We can \hgcmd{update} back and forth between the tips of the
%\texttt{foo} and \texttt{bar} branches without needing to use the
%\hgopt{update}{-C} option, because this only involves going backwards
%and forwards linearly through our change history.
%\interaction{branch-named.update-switchy}

\texttt{foo}$B$H(B\texttt{bar}$B$N(Btip$B$N4V$r(B\hgcmd{update}$B%3%^%s%I$G9T$-Mh$9$k$3(B
$B$H$,$G$-$k!%$3$NA`:n$O99?7MzNr$NCf$r@~7A$K0\F0$9$k$@$1$J$N$G!$(B
\hgopt{update}{-C}$B%*%W%7%g%s$OI,MW$J$$!%(B
\interaction{branch-named.update-switchy}

%If we go back to the \texttt{foo} branch and then run \hgcmd{update},
%it will keep us on \texttt{foo}, not move us to the tip of
%\texttt{bar}.
%\interaction{branch-named.update-nothing}

\texttt{foo}$B%V%i%s%A$XLa$j!$(B\hgcmd{update}$B$r<B9T$7$F$b!$(B\texttt{bar}$B$N(B
tip$B$K$O0\F0$;$:!$(B\texttt{foo}$B$N$^$^$G$"$k!%(B
\interaction{branch-named.update-nothing}

%Committing a new change on the \texttt{foo} branch introduces a new
%head.
%\interaction{branch-named.foo-commit}

$B?7$7$$JQ99$r(B\texttt{foo}$B$K%3%_%C%H$9$k$H!$?7$7$$(Bhead$B$,:n$i$l$k!%(B
\interaction{branch-named.foo-commit}

%\section{Branch names and merging}
\section{$B%V%i%s%AL>$H%^!<%8(B}

%As you've probably noticed, merges in Mercurial are not symmetrical.
%Let's say our repository has two heads, 17 and 23.  If I
%\hgcmd{update} to 17 and then \hgcmd{merge} with 23, Mercurial records
%17 as the first parent of the merge, and 23 as the second.  Whereas if
%I \hgcmd{update} to 23 and then \hgcmd{merge} with 17, it records 23
%as the first parent, and 17 as the second.

$B$*$=$i$/5$$E$$$F$$$k$3$H$H;W$&$,!$(BMercurial$B$G$N%^!<%8$OBP>NE*$G$O$J$$!%(B
$B:#!$%j%]%8%H%j$,(B17$B$H(B23$B$H$$$&(B2$B$D$N(Bhead$B$r;}$D$H$7$h$&!%$3$3$G(B
\hgcmd{update}$B$G(B17$B$K99?7$7!$(B\hgcmd{merge}$B$K$h$C$F(B23$B$H%^!<%8$9$k$H!$(B
Mercurial$B$O(B17$B$r%^!<%8$N:G=i$N?F!$(B23$B$r(B2$BHVL\$N?F$H$7$F5-O?$9$k!%5U$K(B
\hgcmd{update}$B$G(B23$B$K99?7$7!$(B\hgcmd{merge}$B$G(B17$B$H%^!<%8$9$l$P!$(B23$B$r:G=i$N(B
$B?F!$(B17$B$r(B2$BHVL\$N?F$H5-O?$9$k!%(B

%This affects Mercurial's choice of branch name when you merge.  After
%a merge, Mercurial will retain the branch name of the first parent
%when you commit the result of the merge.  If your first parent's
%branch name is \texttt{foo}, and you merge with \texttt{bar}, the
%branch name will still be \texttt{foo} after you merge.

$B$3$l$O%^!<%8$N:]$K(BMercurial$B$,%V%i%s%AL>$r$I$N$h$&$KA*$V$+$K1F6A$rM?$($k!%(B
$B%^!<%88e!"%^!<%8$N7k2L$r%3%_%C%H$9$k:]$K(BMercurial$B$O(B1$BHVL\$N?F$N%V%i%s%AL>(B
$B$rMQ$$$k!%(B1$BHVL\$N?F$N%V%i%s%AL>$,(B\texttt{foo}$B$G!$(B\texttt{bar}$B$H%^!<%8$r(B
$B9T$J$C$?$H$9$k$H!$%^!<%88e$N%V%i%s%AL>$O(B\texttt{foo}$B$H$J$k!%(B

%It's not unusual for a repository to contain multiple heads, each with
%the same branch name.  Let's say I'm working on the \texttt{foo}
%branch, and so are you.  We commit different changes; I pull your
%changes; I now have two heads, each claiming to be on the \texttt{foo}
%branch.  The result of a merge will be a single head on the
%\texttt{foo} branch, as you might hope.

1$B$D$N%j%]%8%H%j$,F1$8%V%i%s%AL>$r;}$D$$$/$D$b$N(Bhead$B$r;}$C$F$$$k$3$H$ODA$7(B
$B$$$3$H$G$O$J$$!%:#!$;d$H$"$J$?$,F1$8(B\texttt{foo}$B%V%i%s%A$G:n6H$r$7$F$*$j!$(B
$B$=$l$>$l0[$J$C$?JQ99$r%3%_%C%H$9$k$H$7$h$&!%$"$J$?$N9T$J$C$?JQ99$r;d$,(B
pull$B$9$k$H!$;d$O(B\texttt{foo}$B%V%i%s%A$K(B2$B$D$N(Bhead$B$r;}$D$3$H$K$J$k!%%^!<%8(B
$B$N7k2L$O!$$"$J$?$,4|BT$9$k$h$&$K(B\texttt{foo}$B%V%i%s%A>e$G(B1$B$D$N(Bhead$B$K$J$k!%(B

%But if I'm working on the \texttt{bar} branch, and I merge work from
%the \texttt{foo} branch, the result will remain on the \texttt{bar}
%branch.
%\interaction{branch-named.merge}

$B$7$+$7!$;d$,(B\texttt{bar}$B%V%i%s%A$G:n6H$r$7$F$$$F!$(B\texttt{foo}$B%V%i%s%A$+(B
$B$i%^!<%8$r9T$J$&$H!$@.2LJ*$O(B\texttt{bar}$B%V%i%s%A$K;D$k$3$H$K$J$k!%(B
\interaction{branch-named.merge}

%To give a more concrete example, if I'm working on the
%\texttt{bleeding-edge} branch, and I want to bring in the latest fixes
%from the \texttt{stable} branch, Mercurial will choose the ``right''
%(\texttt{bleeding-edge}) branch name when I pull and merge from
%\texttt{stable}.

$B$b$C$H6qBNE*$JNc$r5s$2$k$H!$$b$7;d$,(B\texttt{bleeding-edge}$B%V%i%s%A$G:n6H(B
$B$r$7$F$$$F!$(B\texttt{stable}$B%V%i%s%A$N?7$7$$=$@5$r<h$j9~$`$?$a$K(B
\texttt{stable}$B$+$i(Bpull$B$H(Bmerge$B$r9T$J$&$H!$(BMercurial$B$O(B``$B@5$7$$(B''$B%V%i%s%AL>(B
(\texttt{bleeding-edge})$B$rA*$V!%(B

%\section{Branch naming is generally useful}
\section{$B%V%i%s%A$KL>A0$rIU$1$k$3$H$OLr$KN)$D(B}

%You shouldn't think of named branches as applicable only to situations
%where you have multiple long-lived branches cohabiting in a single
%repository.  They're very useful even in the one-branch-per-repository
%case.  

$BL>A0IU$-%V%i%s%A$r(B1$B$D$N%j%]%8%H%j$NCf$KD9L?$J%V%i%s%A$rJ#?t;}$D>u67$K$N$_(B
$BMQ$$$k$Y$-$@$H9M$($k$Y$-$G$O$J$$!%L>A0IU$-%V%i%s%A$O%V%i%s%AKh$K%j%]%8%H(B
$B%j$r;}$D>l9g$G$b6K$a$FM-MQ$G$"$k!%(B

%In the simplest case, giving a name to each branch gives you a
%permanent record of which branch a changeset originated on.  This
%gives you more context when you're trying to follow the history of a
%long-lived branchy project.

$B:G$bC1=c$JNc$O!$$=$l$>$l$N%V%i%s%A$KL>A0$rM?$($k$3$H$G!$%A%'%s%8%;%C%H$,(B
$B$I$N%V%i%s%A$r5/8;$K;}$D$N$+1JB3E*$K5-O?$9$k$3$H$,$G$-$k!%$3$l$K$h$j!$D9(B
$BL?$J%V%i%s%A$r;}$D%W%m%8%'%/%H$NNr;K$rDI$$$+$1$k;~$K!$A08e4X78$,DO$_$d$9(B
$B$/$J$k!%(B

%If you're working with shared repositories, you can set up a
%\hook{pretxnchangegroup} hook on each that will block incoming changes
%that have the ``wrong'' branch name.  This provides a simple, but
%effective, defence against people accidentally pushing changes from a
%``bleeding edge'' branch to a ``stable'' branch.  Such a hook might
%look like this inside the shared repo's \hgrc.
%\begin{codesample2}
%  [hooks]
%  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
%\end{codesample2}

$B6&M-%j%]%8%H%j$r;H$C$F:n6H$7$F$$$k>l9g!$(B\hook{pretxnchangegroup}$B%U%C%/$r(B
$B@_Dj$9$k$3$H$G4V0c$C$?%V%i%s%AL>$r;}$D99?7$r%V%m%C%/$9$k$3$H$,$G$-$k!%$3(B
$B$l$ONc$($P(B``$B:G@hC<(B''$B%V%i%s%A$+$i(B``$B0BDj(B''$B%V%i%s%A$XJQ99$r(Bpush$B$9$k$h$&$J4V(B
$B0c$$$rKI$0$N$K%7%s%W%k$+$D8z2LE*$JJ}K!$G$"$k!%%U%C%/$O!$Nc$($P6&M-%j%]%8(B
$B%H%j$N(B \hgrc $B$K(B
\begin{codesample2}
  [hooks]
  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
\end{codesample2}
$B$N$h$&$K5-=R$5$l$k!%(B


%%% Local Variables: 
%%% mode: yatex
%%% TeX-master: "00book"
%%% End: