Mercurial > hgbook

--- a/ja/branch.tex	Mon Feb 18 06:48:59 2008 +0900
+++ b/ja/branch.tex	Tue Feb 19 00:33:24 2008 +0900
@@ -229,13 +229,13 @@
 %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$NIT9,$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!%(B
-$B$=$N$?$a!$%^!<%8Cf$K(B\sfilename{.hgtags}$B$N%3%s%U%j%/%H2r7h$r$7$F$$$k>l9g(B
-$B$O!$%3%_%C%H8e$KK:$l$:(B\hgcmd{tags}$B$r<B9T$9$kI,MW$,$"$k!%(B
-\sfilename{.hgtags}$B$K%(%i!<$,8+$D$+$C$?>l9g!$%(%i!<$N$"$k>l=j$rJs9p$9$k!%(B
-$B$=$l$r8+$F=$@5$7!$%3%_%C%H$9$k$3$H$,$G$-$k!%$=$3$G(B\hgcmd{tags}$B$r:F$SAv$i(B
-$B$;!$=$@5$,@5$7$$$3$H$r3NG'$9$Y$-$G$"$k!%(B
+$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}
@@ -252,85 +252,141 @@
 $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 result
-is 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.
+%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''.
+%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.
+%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.
+%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.
+%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.
+%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'' 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.
+\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.
+%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}
-You can then clone a new shared \texttt{myproject-1.0.1} repository as
-of that 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.
+%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}
-Meanwhile, development for the next major release can continue,
-isolated and unabated, in the \texttt{myproject} repository.
+$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}