# HG changeset patch
# User Yoshiki Yazawa <yaz@cc.rim.or.jp>
# Date 1202474614 -32400
# Node ID 6a31e428ba3bd4c5a9948cd5889489ec7916e47f
# Parent  828f5606faf0b460d92d938fbd8e77b2b8195830
more branch.tex

diff -r 828f5606faf0 -r 6a31e428ba3b ja/branch.tex
--- a/ja/branch.tex	Fri Feb 08 19:44:10 2008 +0900
+++ b/ja/branch.tex	Fri Feb 08 21:43:34 2008 +0900
@@ -113,46 +113,85 @@
 表示する．
 \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.
+%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.
+%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.
+%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}.  
+%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}
-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.
+タグはいつでも変更できるので，あるタグを他のリビジョンに付け替えるような
+こともできる．
+タグを\emph{本当}に更新したい場合は\hgopt{tag}{-f}オプションを指定する必
+要がある．
 \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.
+タグの以前のアイデンティティーの永続的な記録は残っているが，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
-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}.
+%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はタグをリポジトリの中の通常のリビジョン管理ファイルに保存する．
+タグを作成した時，\sfilename{.hgtags}というファイルにタグが保存されてい
+るのが分かるだろう．\hgcmd{tag}コマンドを実行するとMercurialはこのファイ
+ルを変更し，変更をこのファイルにコミットする．つまり\hgcmd{tag}を実行す
+るといつも\hgcmd{log}の出力の中に対応するチェンジセットを見ることになる．
 \interaction{tag.tip}
 
 %\subsection{Handling tag conflicts during a merge}
@@ -182,12 +221,16 @@
 %\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.
+%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
@@ -266,7 +309,7 @@
 \interaction{branch-repo.new}
 
 %\section{Don't repeat yourself: merging across branches}
-\section{自動化されたブランチ間でのマージ}
+\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