Mercurial > hgbook
changeset 296:89db0aaf6a29
translated chapter & section name within branch.tex.
author | Yoshiki Yazawa <yaz@cc.rim.or.jp> |
---|---|
date | Fri, 08 Feb 2008 01:56:29 +0900 |
parents | c8e9599794c1 |
children | b8105146706f |
files | ja/branch.tex ja/todo.txt |
diffstat | 2 files changed, 24 insertions(+), 14 deletions(-) [+] |
line wrap: on
line diff
--- a/ja/branch.tex Fri Feb 08 01:45:58 2008 +0900 +++ b/ja/branch.tex Fri Feb 08 01:56:29 2008 +0900 @@ -1,4 +1,5 @@ -\chapter{Managing releases and branchy development} +%\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 @@ -16,7 +17,8 @@ about the flow of work between different phases of a project, and how Mercurial can help you to isolate and manage this work. -\section{Giving a persistent name to a revision} +%\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. @@ -103,7 +105,8 @@ corresponding changeset in the output of \hgcmd{log}. \interaction{tag.tip} -\subsection{Handling tag conflicts during a merge} +%\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 @@ -126,7 +129,8 @@ which you can then fix and commit. You should then run \hgcmd{tags} again, just to be sure that your fix is correct. -\subsection{Tags and cloning} +%\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 @@ -144,7 +148,8 @@ 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. -\subsection{When permanent tags are too much} +%\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 @@ -162,7 +167,8 @@ create using \hgopt{tag}{-l} remain strictly local to the repository you're currently working in. -\section{The flow of changes---big picture vs. little} +%\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 @@ -186,7 +192,8 @@ narrative of how the code was developed. \end{itemize} -\section{Managing big-picture branches in repositories} +%\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 @@ -208,7 +215,8 @@ isolated and unabated, in the \texttt{myproject} repository. \interaction{branch-repo.new} -\section{Don't repeat yourself: merging across branches} +%\section{Don't repeat yourself: merging across branches} +\section{$B<+F02=$5$l$?%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 @@ -224,7 +232,8 @@ to the main branch. \interaction{branch-repo.merge} -\section{Naming branches within one repository} +%\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 @@ -298,7 +307,8 @@ names tend to have fairly long lifetimes. (This isn't a rule, just an observation.) -\section{Dealing with multiple named branches in a repository} +%\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 @@ -334,7 +344,8 @@ \hgopt{update}{-C} option to \hgcmd{update}. \interaction{branch-named.update-bar} -\section{Branch names and merging} +%\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 @@ -367,7 +378,8 @@ (\texttt{bleeding-edge}) branch name when I pull and merge from \texttt{stable}. -\section{Branch naming is generally useful} +%\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