comparison ja/branch.tex @ 835:8a3041e6f3cb

reflect comments by Hiroshi Someya.

834:896ab6eaf1c6

%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

%\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.

%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

%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.

%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

%\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}

%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

$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

$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

%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

%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}

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

835:8a3041e6f3cb

%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$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

%\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%\%kL>$KB>$J$i$J$$!%%?%0$OC1$K(B
$B%f!<%6$NJX59$N$?$a$KIU$1$i$l$k!%%?%0$OFCDj$N%j%S%8%g%s$r;2>H$9$k$?$a$N<j(B
$B7Z$G1JB3E*$JJ}K!$G!$(BMercurial$B$O%?%0$rK]Lu$7$J$$!%%?%0$NL>A0$K$O!$L@3N$K%Q!<(B
$B%9$9$k$?$a$KI,MW$J$$$/$D$+$N$b$N0J30$K@)8B$O$J$$!%%?%0%M!<%`$O0J2<$NJ8;z(B
$B$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.

%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$1$d$9$/(B
$B$9$k$?$a$K;H$&$b$N$@$+$i$@!%%?%0$rB?$/IU$1$9$.$k$H!$%?%0$K$h$C$F%j%S%8%g(B
$B%s$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

%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%'%/%H$NMzNr$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$K(B
$BL>A0$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.

%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=`Hw$K$+$+$C$F$$$k>uBV$G!$:G?7$N%a%$%s%j%j!<(B
$B%9$KBP$9$k?7$7$$>.5,LO$J%P%0%U%#%C%/%9%j%j!<%9$H!$4{$K%a%s%F%J%s%9%b!<%I(B
$B$K$J$C$F$$$k8E$$%j%j!<%98~$1$N7W2h30$N(B``hot fix''$B$r%j%j!<%9$9$k>u67$r9M$((B
$B$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

%\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``big 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}

%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$KBP$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

$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?$NMzNr$b@8@.$5$l$F$$$J(B
$B$$!%$3$l$+$iJ,$+$k$h$&$K!$(B\hgcmd{branch}$B%3%^%s%I$r<B9T$7$F$b!$1JB3E*$J8z(B
$B2L$O2?$b5/$-$J$$!%$3$N%3%^%s%I$O(B\emph{$B<!$N(B}$B%A%'%s%8%;%C%H$N%3%_%C%H$,$I$N(B
$B%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

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

%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?6Iq$$$O$d$d4q0[$+$b$7$l$J$$!%<B:]$NF0:n$r8+$F$_$k$3$H$K$9$k!%$^$:2f!9(B
$B$,$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$_$h(B
$B$&!%(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

%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$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$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$&$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$&$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}

%\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!$6&M-%j%]%8%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: