%\chapter{Managing releases and branchy development}
\chapter{リリースとブランチ開発の管理}
\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は同時に複数の局面で進行していくプロジェクトを管理するのに役立
つ機能を持っている．これらの機能を理解するため，まず通常のソフトウェアプ
ロジェクトの構造を考える．

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

多くのソフトウェアプロジェクトでは，新機能を持つメジャーリリースを定期的
にリリースする．並行して多数のマイナーリリースも行われる．これらはメ
ジャーリリースのバグを修正したものである．

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

この章ではまずリリースのようなプロジェクトのマイルストーンに言及する．次い
でプロジェクトの各フェーズでの流れを説明し，Mercurialでどのように区分け
し，管理できるのかを説明する．

%\section{Giving a persistent name to a revision}
\section{リビジョンに永続的な名前を付ける}

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

あるリビジョンをリリースと決めた時に，これを記録しておくのは良い考えであ
る．これは後日，バグの再現やソフトウェアの移植などの目的でリリースを再現
するのに役立つ．
\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}

特定のリビジョンにMercurialで永続的な名前を付けることができる．この名前
はタグと呼ばれる．
\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}

タグは実のところリビジョンに付けられたシンボル名に他ならない．タグは単に
ユーザの便宜のために付けられる．タグは特定のリビジョンを参照するための手
軽で永続的な方法で，Mercurialはタグを翻訳しない．タグの名前には，明確にパー
スするために必要ないくつかのもの以外に制限はない．タグネームは以下の文字
を含むことはできない．
\begin{itemize}
\item コロン (ASCII 58, ``\texttt{:}'')
\item 復帰文字 (ASCII 13, ``\Verb+\r+'')
\item 改行文字 (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}コマンドでリポジトリに存在するタグを表示することができる．出
力では，タグ付けされたリビジョンは名前，リビジョン番号，固有のハッシュ値
の順に区別される．
\interaction{tag.tags}
\hgcmd{tags}の出力に\texttt{tip}が含まれていることに注意．\texttt{tip}タ
グは，リポジトリの中で常に最新のリビジョンに付けられている特別なフローティ
ングタグである．

%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}コマンドの出力において，タグはリビジョン番号によって逆順で表
示されている．これによって，通常，新しいタグが古いタグよりも前に表示され
る．\texttt{tip}タグは\hgcmd{tags}コマンドの出力の一番先頭に表示される．

%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}コマンドはタグの結びつけられたリビジョンを表示する際にタグも
表示する．
\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コマンドにリビジョン番号を渡す必要がある場合，常にタグネームを使
うことができる．内部的にはMercurialはタグネームを対応するリビジョンIDに
変換して使用している．
\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.

リポジトリの中で使えるタグ数，一つのリビジョンに付けられるタグ数に上限は
ない．事情はプロジェクトによって異なるだろうが，実用的にはタグを多く付け
すぎることはあまり良い考えとは言えない．タグとはリビジョンを見つけやすく
するために使うものだからだ．タグを多く付けすぎると，タグによってリビジョ
ンの区別をすることがとたんに難しくなる．

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

例えばあなたのプロジェクトが数日毎にマイルストーンを迎えている場合，それ
ぞれにタグを付けることは理に適っている．しかし，それぞれのリビジョンがク
リーンにビルドできるか検証するためのビルドシステムを持っているような場合，
それぞれのクリーンビルドにタグを付けていたら収拾がつかなくなるだろう．む
しろビルドが失敗することが少ないのであれば，失敗したリビジョンにタグをつ
けた方が良いし，単にビルドが通ったことを示すのにタグを用いるべきではない
かも知れない．

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

タグが必要なくなった時は\hgcmdargs{tag}{--remove}コマンドで消すことがで
きる．
\interaction{tag.remove}
タグはいつでも変更できるので，あるタグを他のリビジョンに付け替えるような
こともできる．
タグを\emph{本当}に更新したい場合は\hgopt{tag}{-f}オプションを指定する必
要がある．
\interaction{tag.replace}
タグの以前のアイデンティティーの永続的な記録は残っているが，Mercurialはも
はやこれを利用しない．よって，間違ったリビジョンにタグを付けることでペナ
ルティが課せられるということはない．間違いを見つけた時は単にやり直して正
しいリビジョンにタグを付ければよい．

%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 in
%the root of your repository 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はタグをリポジトリの中の通常のリビジョン管理ファイルに保存する．
タグを作成した時，リポジトリのルートにある\sfilename{.hgtags}というファイ
ルにタグが保存されているのが分かるだろう．\hgcmd{tag}コマンドを実行すると
Mercurialはこのファイルを変更し，変更をこのファイルにコミットする．つまり
\hgcmd{tag}を実行するといつも\hgcmd{log}の出力の中に対応するチェンジセッ
トを見ることになる． \interaction{tag.tip}

%\subsection{Handling tag conflicts during a merge}
\subsection{マージの際にタグのコンフリクトを解決する}

%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}を気にしなければならないことは多くないが，マージの際に
は存在を明らかにする．ファイルフォーマットはシンプルで，一連の行を含むだ
けである．それぞれの行はチェンジセットのハッシュで始まり，1つのスペース
が続き，タグの名称が続く．

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

マージ中に\sfilename{.hgtags}ファイル内のコンフリクトを解決している場合，
\sfilename{.hgtags}を変更する一捻りがある．Mercurialがリポジトリ中のタグ
をパースする時，Mercurialは\sfilename{.hgtags}のワーキングコピーを
\emph{決して}読まない．その代わり\emph{最も新しくコミットされた}リビジョ
ンを読む．

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

この設計の残念な結果は，変更をコミットした\emph{後}でないとマージした
\sfilename{.hgtags}ファイルを実際にはベリファイできないことである．そのた
め，マージ中に\sfilename{.hgtags}のコンフリクト解決をしている場合は，コミッ
ト後に忘れず\hgcmd{tags}を実行する必要がある．\sfilename{.hgtags}にエラー
が見つかった場合，エラーのある場所を報告する．それを見て修正し，コミット
することができる．そこで\hgcmd{tags}を再び走らせ，修正が正しいことを確認
すべきである．


%\subsection{Tags and cloning}
\subsection{タグとクローン}

%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}コマンドが\hgopt{clone}{-r}オプションを持っていることにすで
に気づいているかも知れない．このオプションで特定のチェンジセットのコピー
をクローンすることができるが、クローンしたコピーは，指定したリビジョン後
の履歴を持たないため、不用心なユーザはしばしば驚くことになる。

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

タグは\sfilename{.hgtags}ファイル内のリビジョンとして記録されていることを
思い出して欲しい．このため，タグ作成時に，タグが記録されているチェンジセッ
トから古いチェンジセットへの参照が生じる．タグ\texttt{foo}が付いているリ
ポジトリをクローンするために\hgcmdargs{clone}{-r foo}実行する時，新しいク
ローンはタグを生成した履歴を\emph{含まない}．結果として，新しいリポジトリ
に含まれる履歴は，プロジェクト履歴のサブセットになり，タグは含まれない．


%\subsection{When permanent tags are too much}
\subsection{永久タグが必要でない場合}

%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のタグはリビジョンコントロールされ，プロジェクトの履歴に付随して
いるため，同じプロジェクトで働く人は皆タグを知ることになる．リビジョンに
名前を付けることは，単にリビジョン\texttt{4237e45506ee}がバージョン
\texttt{v2.0.2}であると記述する以上の意味を持つ．もしバグを追跡しているな
ら，``Anne saw the symptoms with this revision''（アンはこのリビジョンで
症状を見た）などのタグを付けたくなるだろう．

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

このような場合，\emph{ローカル}タグを使いたくなるはずだ．ローカルタグは
\hgcmd{tag}コマンドを\hgopt{tag}{-l}オプション付きで使うことで作成できる．
このオプションを使うと，タグは\sfilename{.hg/localtags}というファイルに保
存される．\sfilename{.hgtags}と違って，\sfilename{.hg/localtags}はリビジョ
ンコントロールされない．\hgopt{tag}{-l}オプションで作成したあらゆるタグ
は厳密にローカルに管理され，今作業しているろポジ取りには一切反映されない．


%\section{The flow of changes---big picture vs. little}
\section{更新の流れ---大局的 vs.局所的}

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

この章の最初で示したアウトラインに戻るために，プロジェクトが開発中，一度
に複数の並行した部分を持つと考えよう．

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

新しい``main''をリリースする準備にかかっている状態で，最新のメインリリー
スに対する新しい小規模なバグフィックスリリースと，既にメンテナンスモード
になっている古いリリース向けの計画外の``hot fix''をリリースする状況を考え
る．


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

人々が，異なった並行的な開発の方向性について触れる時は，``ブランチ''とし
て言及する．しかし，既に幾度となくMercurialが\emph{全ての履歴}を一連のブ
ランチとマージとして取り扱っているのを見てきた．ここでは，わずかに関連し
ているが名前を共有している2つのアイディアを考える．
\begin{itemize}
\item ``Big picture''ブランチはプロジェクトの進化を表す．開発者はこれら
      に名前を与え，会話で用いる．
\item ``Little picture''ブランチは日々の開発とマージの所産で，コードがど
      のように開発されたかを示すものである．
\end{itemize}

%\section{Managing big-picture branches in repositories}
\section{リポジトリ間での大局的ブランチの管理}

%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で``big picture''を隔離する最も簡単な方法は，専用のリポジトリを
用意することである．もし一つの共有リポジトリを持っている場合，これを
\texttt{myproject}と呼ぶことにしる．これが``1.0''マイルストーンに到達した
ら，1.0に1.0リリースとタグを付け，将来のメンテナンスリリースに備えること
ができる．
\interaction{branch-repo.tag}
そして新たに\texttt{myproject-1.0.1}とタグを付けてリポジトリをクローンす
る．
\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}

以後，バグフィックスをしたい人は1.0.1マイナーリリースへいくべきである．
彼らは\texttt{myproject-1.0.1}リポジトリをクローンし，変更を加え，プッシュ
する．
\interaction{branch-repo.bugfix}
一方で次のメジャーリリースに向けての開発は，\texttt{myproject}リポジトリ
の中で隔離され，滞る事なく継続することが可能である．
\interaction{branch-repo.new}

%\section{Don't repeat yourself: merging across branches}
\section{手で繰り返さないこと：ブランチ間でのマージ}

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

メンテナンスブランチで修正すべきバグがあるとき，多くの場合，メインブラン
チにそのバグがある可能性は高い．（さらに他のメンテナンスブランチにおいて
も．）バグの修正を何度も繰り返したいと思う開発者はまずいない．そこでバグ
修正を繰り返す代わりのではなく，Mercurialで解決できるいくつかの方法を見
てみることにしよう．

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

最も簡単なのは，メンテナンスブランチから変更をターゲットブランチのローカ
ルクローンにpullする方法である．
\interaction{branch-repo.pull}
その後2つのブランチのヘッド同士をマージし，メインブランチへプッシュする．
\interaction{branch-repo.merge}

%\section{Naming branches within one repository}
\section{1つのリポジトリ内でのブランチの命名}

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

多くの場合，ブランチ毎に複数のリポジトリを用意し隔離するのは正しいアプロー
チである．これは単純なため把握が容易であり，失敗を犯す可能性が低い．作業
しているブランチとディレクトリの間には1対1の関係がある．Mercurialを考慮し
ない通常のツールをブランチ／リポジトリ内のファイルに対して使うことも可能
である．

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

あなたと（あなたの協力者が\emph{共に}）``パワーユーザ''以上のカテゴリに属
すなら，ブランチを取り扱う別の方法も考えられる．すでに``局所的なモデル''
と``大局的なモデル''という，区別について触れた．Mercurialは，複数の``局所
的な''ブランチ（たとえば変更をpullしてマージしていない場合など）用いるこ
とができる一方で，複数の``大局的な''ブランチを用いること\emph{も}できる．

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

この方法を用いる際の鍵は，Mercurialによってブランチに永続的な\emph{名前}
を付けることである．ブランチに名前を付ける前でも，\texttt{default}ブラン
チのトレースを見ることができる．

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

例として，\hgcmd{commit}コマンドを実行し，コミットメッセージを書くために
エディタが起動された時，最下部の``\texttt{HG: branch default}''という行
を見てほしい．この行はコミットが\texttt{default}という名前のブランチに対
して行われることを示している．

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

名前付きブランチを使うにあたって，まず\hgcmd{branches}を使い，リポジトリ
内にすでに存在する名前付きブランチを列挙することから始める．このコマンド
によってそれぞれのブランチのtipになっているチェンジセットがわかる．
\interaction{branch-named.branches}
ここではまだ名前付きブランチを作っていないので，\texttt{default}ブランチ
だけが存在する．

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

現在のブランチが何なのかを知るためには，\hgcmd{branch}コマンドを引数なし
で実行する．このコマンドで現在のチェンジセットの親ブランチがわかる．
\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}

新しいブランチを作るのにも\hgcmd{branch}コマンドを使う．この場合は，作成
したいブランチの名前を引数として渡す．
\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.

ブランチを作った後で\hgcmd{branch}コマンドがどのような効果を持っているの
か分からないかもしれない．\hgcmd{status}コマンドと\hgcmd{tip}コマンドは
それぞれ何を表示するだろうか？
\interaction{branch-named.status}
ワーキングディレクトリ内では何も変化は起きず，何の履歴も生成されていな
い．これから分かるように，\hgcmd{branch}コマンドを実行しても，永続的な効
果は何も起きない．このコマンドは\emph{次の}チェンジセットのコミットがどの
ブランチに対して行われるかをMercurialコマンドに示すのに使われる．

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

変更をコミットする時，Mercurialはコミットするの対象になるブランチの名前
を記録する．ひとたび\texttt{default}から他へ変更すれば，新しいブランチ名
が\hgcmd{log}や\hgcmd{tip}の出力に含まれるのが見て取れるだろう．
\interaction{branch-named.commit}
\hgcmd{log}のようなコマンドは，\texttt{default}ブランチ以外に属するすべて
のチェンジセットに対してブランチ名を表示する．ブランチに名前を付けていな
い場合はこの出力を目にすることはない．

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

ブランチに名前を付け，その名前を使って変更のコミットを行うと，以後に続く
全てのコミットは同じ名前を持つ．名前の変更は\hgcmd{branch}コマンドを使うこ
とでいつでも可能だ．
\interaction{branch-named.rebranch}
実用においては，ブランチ名はかなり長い期間使われる傾向があり，変更は頻繁
には行われない．（これは法則と言えるようなものではなく，単なる観測結果で
ある．）

%\section{Dealing with multiple named branches in a repository}
\section{リポジトリ内で複数の名前の付いたブランチの取り扱い}

%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つのリポジトリ内に2つ以上のブランチを持っている場合，Mercurialは，
\hgcmd{update}や\hgcmdargs{pull}{-u}のようなコマンドを立ち上げるときに，
ワーキングディレクトリがどのブランチであるか記憶している．
これらのコマンドは，リポジトリ全体でのtipが何であるかには関係なく，ワーキ
ングディレクトリを現在のブランチのtipに更新する．
他の名前つきブランチに属すリビジョンへ更新するには，\hgopt{update}{-C}オ
プション付きで\hgcmd{update}コマンドを実行する必要があるかもしれない．

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

この振舞いはやや奇異かもしれない．実際の動作を見てみることにする．まず我々
がどのブランチにいるかを調べ，リポジトリにどんなブランチがあるか見てみよ
う．
\interaction{branch-named.parents}
今いるのは\texttt{bar}ブランチで，\texttt{foo}ブランチも存在する．

%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}と\texttt{bar}のtipの間を\hgcmd{update}コマンドで行き来するこ
とができる．この操作は更新履歴の中を線形に移動するだけなので，
\hgopt{update}{-C}オプションは必要ない．
\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}ブランチへ戻り，\hgcmd{update}を実行しても，\texttt{bar}の
tipには移動せず，\texttt{foo}のままである．
\interaction{branch-named.update-nothing}

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

新しい変更を\texttt{foo}にコミットすると，新しいheadが作られる．
\interaction{branch-named.foo-commit}

%\section{Branch names and merging}
\section{ブランチ名とマージ}

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

おそらく気づいていることと思うが，Mercurialでのマージは対称的ではない．
今，リポジトリが17と23という2つのheadを持つとしよう．ここで
\hgcmd{update}で17に更新し，\hgcmd{merge}によって23とマージすると，
Mercurialは17をマージの最初の親，23を2番目の親として記録する．逆に
\hgcmd{update}で23に更新し，\hgcmd{merge}で17とマージすれば，23を最初の
親，17を2番目の親と記録する．

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

これはマージの際にMercurialがブランチ名をどのように選ぶかに影響を与える．
マージ後、マージの結果をコミットする際にMercurialは1番目の親のブランチ名
を用いる．1番目の親のブランチ名が\texttt{foo}で，\texttt{bar}とマージを
行ったとすると，マージ後のブランチ名は\texttt{foo}となる．

%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つのリポジトリが同じブランチ名を持ついくつものheadを持っていることは珍し
いことではない．今，私とあなたが同じ\texttt{foo}ブランチで作業をしており，
それぞれ異なった変更をコミットするとしよう．あなたの行った変更を私が
pullすると，私は\texttt{foo}ブランチに2つのheadを持つことになる．マージ
の結果は，あなたが期待するように\texttt{foo}ブランチ上で1つのheadになる．

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

しかし，私が\texttt{bar}ブランチで作業をしていて，\texttt{foo}ブランチか
らマージを行うと，成果物は\texttt{bar}ブランチに残ることになる．
\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}.

もっと具体的な例を挙げると，もし私が\texttt{bleeding-edge}ブランチで作業
をしていて，\texttt{stable}ブランチの新しい修正を取り込むために
\texttt{stable}からpullとmergeを行うと，Mercurialは``正しい''ブランチ名
(\texttt{bleeding-edge})を選ぶ．

%\section{Branch naming is generally useful}
\section{ブランチに名前を付けることは役に立つ}

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

名前付きブランチを1つのリポジトリの中に長命なブランチを複数持つ状況にのみ
用いるべきだと考えるべきではない．名前付きブランチはブランチ毎にリポジト
リを持つ場合でも極めて有用である．

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

最も単純な例は，それぞれのブランチに名前を与えることで，チェンジセットが
どのブランチを起源に持つのか永続的に記録することができる．これにより，長
命なブランチを持つプロジェクトの歴史を追いかける時に，前後関係が掴みやす
くなる．

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

共有リポジトリを使って作業している場合，\hook{pretxnchangegroup}フックを
設定することで間違ったブランチ名を持つ更新をブロックすることができる．こ
れは例えば``最先端''ブランチから``安定''ブランチへ変更をpushするような間
違いを防ぐのにシンプルかつ効果的な方法である．フックは，共有リポジトリの
\hgrc に
\begin{codesample2}
  [hooks]
  pretxnchangegroup.branch = hg heads --template '{branches} ' | grep mybranch
\end{codesample2}
のように記述される．


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