# HG changeset patch
# User Yoshiki Yazawa <yaz@cc.rim.or.jp>
# Date 1202751554 -32400
# Node ID 62ea8107a73ba5e3ea82de967e2c8394f4d41eaf
# Parent  8202b13f770744769779ab86e136e926adf1fd7b
more undo.tex

diff -r 8202b13f7707 -r 62ea8107a73b ja/undo.tex
--- a/ja/undo.tex	Sat Feb 09 00:33:04 2008 +0900
+++ b/ja/undo.tex	Tue Feb 12 02:39:14 2008 +0900
@@ -606,79 +606,140 @@
   \label{fig:undo:backout-manual}
 \end{figure}
 
-After the \hgcmd{backout} command has completed, it leaves the new
-``backout'' changeset as the parent of the working directory.
+%After the \hgcmd{backout} command has completed, it leaves the new
+%``backout'' changeset as the parent of the working directory.
+%\interaction{backout.manual.parents}
+%Now we have two isolated sets of changes.
+%\interaction{backout.manual.heads}
+
+\hgcmd{backout}コマンドは，完了した後，バックアウトチェンジセットをワーキ
+ングディレクトリの親として残す．
 \interaction{backout.manual.parents}
-Now we have two isolated sets of changes.
+ここで2つの隔離された変更のセットが存在することになる．
 \interaction{backout.manual.heads}
 
-Let's think about what we expect to see as the contents of
-\filename{myfile} now.  The first change should be present, because
-we've never backed it out.  The second change should be missing, as
-that's the change we backed out.  Since the history graph shows the
-third change as a separate head, we \emph{don't} expect to see the
-third change present in \filename{myfile}.
+
+%Let's think about what we expect to see as the contents of
+%\filename{myfile} now.  The first change should be present, because
+%we've never backed it out.  The second change should be missing, as
+%that's the change we backed out.  Since the history graph shows the
+%third change as a separate head, we \emph{don't} expect to see the
+%third change present in \filename{myfile}.
+%\interaction{backout.manual.cat}
+%To get the third change back into the file, we just do a normal merge
+%of our two heads.
+%\interaction{backout.manual.merge}
+%Afterwards, the graphical history of our repository looks like
+%figure~\ref{fig:undo:backout-manual-merge}.
+
+今ここで\filename{myfile}の内容を見たいとする．最初の変更はバックアウトし
+ていないので存在しているはずである．2番目の変更はバックアウトしたので消
+えて無くなっているはずだ．3番目の変更は履歴グラフで分離したヘッドとして
+表示されるため，3番目の変更が\filename{myfile}にあるとは期待していない．
 \interaction{backout.manual.cat}
-To get the third change back into the file, we just do a normal merge
-of our two heads.
+3番目の変更をファイルに反映させるためには，2つのヘッドをマージしてやれば
+よい．
 \interaction{backout.manual.merge}
-Afterwards, the graphical history of our repository looks like
-figure~\ref{fig:undo:backout-manual-merge}.
+その後ではリポジトリの履歴のグラフは図
+\ref{fig:undo:backout-manual-merge}のようになる
 
 \begin{figure}[htb]
   \centering
   \grafix{undo-manual-merge}
-  \caption{Manually merging a backout change}
+%  \caption{Manually merging a backout change}
+  \caption{バックアウトチェンジの手動によるマージ}
   \label{fig:undo:backout-manual-merge}
 \end{figure}
 
-\subsection{Why \hgcmd{backout} works as it does}
+%\subsection{Why \hgcmd{backout} works as it does}
+\subsection{なぜ\hgcmd{backout}はこのように動作するのか}
 
-Here's a brief description of how the \hgcmd{backout} command works.
+%Here's a brief description of how the \hgcmd{backout} command works.
+%\begin{enumerate}
+%\item It ensures that the working directory is ``clean'', i.e.~that
+%  the output of \hgcmd{status} would be empty.
+%\item It remembers the current parent of the working directory.  Let's
+%  call this changeset \texttt{orig}
+%\item It does the equivalent of a \hgcmd{update} to sync the working
+%  directory to the changeset you want to back out.  Let's call this
+%  changeset \texttt{backout}
+%\item It finds the parent of that changeset.  Let's call that
+%  changeset \texttt{parent}.
+%\item For each file that the \texttt{backout} changeset affected, it
+%  does the equivalent of a \hgcmdargs{revert}{-r parent} on that file,
+%  to restore it to the contents it had before that changeset was
+%  committed.
+%\item It commits the result as a new changeset.  This changeset has
+%  \texttt{backout} as its parent.
+%\item If you specify \hgopt{backout}{--merge} on the command line, it
+%  merges with \texttt{orig}, and commits the result of the merge.
+%\end{enumerate}
+
+\hgcmd{backout}がどのように動作するか完結に説明すると以下のようになる．
 \begin{enumerate}
-\item It ensures that the working directory is ``clean'', i.e.~that
-  the output of \hgcmd{status} would be empty.
-\item It remembers the current parent of the working directory.  Let's
-  call this changeset \texttt{orig}
-\item It does the equivalent of a \hgcmd{update} to sync the working
-  directory to the changeset you want to back out.  Let's call this
-  changeset \texttt{backout}
-\item It finds the parent of that changeset.  Let's call that
-  changeset \texttt{parent}.
-\item For each file that the \texttt{backout} changeset affected, it
-  does the equivalent of a \hgcmdargs{revert}{-r parent} on that file,
-  to restore it to the contents it had before that changeset was
-  committed.
-\item It commits the result as a new changeset.  This changeset has
-  \texttt{backout} as its parent.
-\item If you specify \hgopt{backout}{--merge} on the command line, it
-  merges with \texttt{orig}, and commits the result of the merge.
+ \item ワーキングディレクトリがクリーンであることを確認する．i.e.\hgcmd{status}
+      が空であることを確認する
+ \item 現在のワーキングディレクトリの親を記憶するこのチェンジセットを
+       \texttt{orig}と呼ぶことにする．
+ \item ワーキングディレクトリを，バックアウトしたチェンジセットの内容に
+       するために\hgcmd{update}と等価な動作を行なう．このチェンジセット
+       を\texttt{backout}と呼ぶ．
+ \item そのチェンジセットの親を見つけ出すこのチェンジセットを
+       \texttt{parent}と呼ぶことにする．
+ \item \texttt{backout}チェンジセットが影響する各々のファイルに対して，
+       \hgcmdargs{revert}{-r parent}と等価な操作を行い，チェンジセットが
+       コミットされる前の状態に戻す．
+ \item 新しいチェンジセットの結果をコミットする．このチェンジセットは
+       \texttt{backout}を親に持つ．
+ \item \hgopt{backout}{--merge}をコマンドラインから入力した場合，
+       \texttt{orig}とのマージを行ない，結果をコミットする．
 \end{enumerate}
 
-An alternative way to implement the \hgcmd{backout} command would be
-to \hgcmd{export} the to-be-backed-out changeset as a diff, then use
-the \cmdopt{patch}{--reverse} option to the \command{patch} command to
-reverse the effect of the change without fiddling with the working
-directory.  This sounds much simpler, but it would not work nearly as
-well.
+%An alternative way to implement the \hgcmd{backout} command would be
+%to \hgcmd{export} the to-be-backed-out changeset as a diff, then use
+%the \cmdopt{patch}{--reverse} option to the \command{patch} command to
+%reverse the effect of the change without fiddling with the working
+%directory.  This sounds much simpler, but it would not work nearly as
+%well.
 
-The reason that \hgcmd{backout} does an update, a commit, a merge, and
-another commit is to give the merge machinery the best chance to do a
-good job when dealing with all the changes \emph{between} the change
-you're backing out and the current tip.  
+\hgcmd{backout}コマンドを実装する別の方法として，\hgcmd{export}でバックア
+ウトされるべきチェンジセットをdiffとして出力し，
+\command{patch}を}\cmdopt{patch}{--reverse}オプション付きで呼び，ワーキン
+グディレクトリの操作を省略してリバースパッチする方法が考えられる．
+この方法はずっと単純だが，ほとんどうまく動かない．
+
+%The reason that \hgcmd{backout} does an update, a commit, a merge, and
+%another commit is to give the merge machinery the best chance to do a
+%good job when dealing with all the changes \emph{between} the change
+%you're backing out and the current tip.  
+
+\hgcmd{backout}がアップデート，コミット，マージ，コミットを行なう理由は，
+バックアウトすべき変更と現在のチップの間で，マージ機構が最も良い結果を得
+られるようにするためである．
 
-If you're backing out a changeset that's~100 revisions back in your
-project's history, the chances that the \command{patch} command will
-be able to apply a reverse diff cleanly are not good, because
-intervening changes are likely to have ``broken the context'' that
-\command{patch} uses to determine whether it can apply a patch (if
-this sounds like gibberish, see \ref{sec:mq:patch} for a
-discussion of the \command{patch} command).  Also, Mercurial's merge
-machinery will handle files and directories being renamed, permission
-changes, and modifications to binary files, none of which
-\command{patch} can deal with.
+%If you're backing out a changeset that's~100 revisions back in your
+%project's history, the chances that the \command{patch} command will
+%be able to apply a reverse diff cleanly are not good,because
+%intervening changes are likely to have ``broken the context'' that
+%\command{patch} uses to determine whether it can apply a patch (if
+%this sounds like gibberish, see \ref{sec:mq:patch} for a
+%discussion of the \command{patch} command).
+%Also, Mercurial's merge machinery will handle files and directories
+%being renamed, permission changes, and modifications to binary files,
+%none of which \command{patch} can deal with.
 
-\section{Changes that should never have been}
+もしプロジェクトの履歴の中で100リビジョンも遡るようなチェンジセットをバッ
+クアウトするとすれば，\command{patch}がdiffを適用できる可能性は明らかに低
+い．間にある変更が，\command{patch}コマンドがパッチ適用の可否を判断するた
+めの文脈を壊している可能性が高いからである．（この話が分からない場合は
+\ref{sec:mq:patch}の\command{patch}コマンドに関する議論を参照して欲しい．）
+また，Mercurialのマージ機構は，\command{patch}コマンドが扱えないファイル
+とディレクトリのリネーム，パーミッション変更，バイナリファイルへの変更な
+どを扱うことができる．
+
+
+%\section{Changes that should never have been}
+\section{すべきでない変更}
 \label{sec:undo:aaaiiieee}
 
 Most of the time, the \hgcmd{backout} command is exactly what you need