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

diff -r 62ea8107a73b -r bb4c3994cec7 ja/undo.tex
--- a/ja/undo.tex	Tue Feb 12 02:39:14 2008 +0900
+++ b/ja/undo.tex	Tue Feb 12 06:09:08 2008 +0900
@@ -739,75 +739,132 @@
 
 
 %\section{Changes that should never have been}
-\section{すべきでない変更}
+\section{存在すべきでない変更}
 \label{sec:undo:aaaiiieee}
 
-Most of the time, the \hgcmd{backout} command is exactly what you need
-if you want to undo the effects of a change.  It leaves a permanent
-record of exactly what you did, both when committing the original
-changeset and when you cleaned up after it.
+%Most of the time, the \hgcmd{backout} command is exactly what you need
+%if you want to undo the effects of a change.  It leaves a permanent
+%record of exactly what you did, both when committing the original
+%changeset and when you cleaned up after it.
+
+大抵の場合，\hgcmd{backout}はある変更を取り消そうとする際に思ったように機
+能するはずである．元々のコミットやそれを取り除いた時に何をしたのか永続的
+な記憶が残される．
 
-On rare occasions, though, you may find that you've committed a change
-that really should not be present in the repository at all.  For
-example, it would be very unusual, and usually considered a mistake,
-to commit a software project's object files as well as its source
-files.  Object files have almost no intrinsic value, and they're
-\emph{big}, so they increase the size of the repository and the amount
-of time it takes to clone or pull changes.
+%On rare occasions, though, you may find that you've committed a change
+%that really should not be present in the repository at all.  For
+%example, it would be very unusual, and usually considered a mistake,
+%to commit a software project's object files as well as its source
+%files.Object files have almost no intrinsic value, and they're
+%\emph{big}, so they increase the size of the repository and the amount
+%of time it takes to clone or pull changes.
+
+それでもたまにリポジトリに全く残したくない変更をコミットしてしまうことが
+ある．たとえば，非常に変なコミットや，通常ミスと考えられるようなコミット，
+ソースだけではなくプロジェクトのオブジェクトファイルもコミットしてしまう
+などが有り得る．オブジェクトファイルは固有の値を持ち得ず，かつ\emph{大き
+い}．そのため，リポジトリのサイズを増やし，クローンやプルに余計な時間が掛
+かるようになる．
+
+%Before I discuss the options that you have if you commit a ``brown
+%paper bag'' change (the kind that's so bad that you want to pull a
+%brown paper bag over your head), let me first discuss some approaches
+%that probably won't work.
 
-Before I discuss the options that you have if you commit a ``brown
-paper bag'' change (the kind that's so bad that you want to pull a
-brown paper bag over your head), let me first discuss some approaches
-that probably won't work.
+茶色の紙袋コミット（茶色の紙袋を頭に被りたいぐらいバツの悪いコミット）に
+使えるオプションについて議論する前に，いくつかのうまく行かないアプローチ
+を述べたい．
+
+%Since Mercurial treats history as accumulative---every change builds
+%on top of all changes that preceded it---you generally can't just make
+%disastrous changes disappear.  The one exception is when you've just
+%committed a change, and it hasn't been pushed or pulled into another
+%repository.  That's when you can safely use the \hgcmd{rollback}
+%command, as I detailed in section~\ref{sec:undo:rollback}.
 
-Since Mercurial treats history as accumulative---every change builds
-on top of all changes that preceded it---you generally can't just make
-disastrous changes disappear.  The one exception is when you've just
-committed a change, and it hasn't been pushed or pulled into another
-repository.  That's when you can safely use the \hgcmd{rollback}
-command, as I detailed in section~\ref{sec:undo:rollback}.
+Mercurialは履歴を累積的なものとして扱う．全ての変更はそれに先立つ全ての変
+更の上になりたっている．一般的に言って破壊的な変更を回避することはできな
+い．たった一つの例外はコミットを行なった直後で，他のリポジトリにプッシュ
+もプルもされていない場合である．その場合，\ref{sec:undo:rollback}のセクショ
+ンで詳しく触れたように，安全に\hgcmd{rollback}を実行することができる．
 
-After you've pushed a bad change to another repository, you
-\emph{could} still use \hgcmd{rollback} to make your local copy of the
-change disappear, but it won't have the consequences you want.  The
-change will still be present in the remote repository, so it will
-reappear in your local repository the next time you pull.
+%After you've pushed a bad change to another repository, you \emph{could}
+%still use \hgcmd{rollback} to make your local copy of the change
+%disappear, but it won't have the consequences you want.  The change will
+%still be present in the remote repository, so it will reappear in your
+%local repository the next time you pull.
+
+間違った変更を他のリポジトリにプッシュした後でもローカ
+ルコピーの変更を取り消すために依然として\hgcmd{rollback}を使うことが
+\emph{できる}が，これは意図したような結果にはならない．変更は依然として
+リモートのリポジトリにはそんざいしており，次にプルした時にはローカルリポ
+ジトリにも現れる．
 
-If a situation like this arises, and you know which repositories your
-bad change has propagated into, you can \emph{try} to get rid of the
-changeefrom \emph{every} one of those repositories.  This is, of
-course, not a satisfactory solution: if you miss even a single
-repository while you're expunging, the change is still ``in the
-wild'', and could propagate further.
+%If a situation like this arises, and you know which repositories your
+%bad change has propagated into, you can \emph{try} to get rid of the
+%changee from \emph{every} one of those repositories.  This is, of
+%course, not a satisfactory solution: if you miss even a single
+%repository while you're expunging, the change is still ``in the
+%wild'', and could propagate further.
+
+このような状況になった時，もしどのリポジトリにこの間違った変更が波及して
+いるのかが明らかであれば，それらのリポジトリの一つ一つから，変更を取り除
+くことを試みることができる．これはもちろん満足のいく解決法ではない．もし
+一つでも消去を忘れれば，変更は野放しになっており，さらに拡がり得る．
 
-If you've committed one or more changes \emph{after} the change that
-you'd like to see disappear, your options are further reduced.
-Mercurial doesn't provide a way to ``punch a hole'' in history,
-leaving changesets intact.
+%If you've committed one or more changes \emph{after} the change that
+%you'd like to see disappear, your options are further reduced.
+%Mercurial doesn't provide a way to ``punch a hole'' in history,
+%leaving changesets intact.
+
+もし1つ以上の新たな変更を，消したいと思っている変更の後にコミットしてい
+たとすれば，使えるオプションはさらに少なくなる．Mercurialはチェンジセッ
+トをそのままに履歴に穴を開けるような方法を提供していない．
 
-XXX This needs filling out.  The \texttt{hg-replay} script in the
-\texttt{examples} directory works, but doesn't handle merge
-changesets.  Kind of an important omission.
+%XXX This needs filling out.  The \texttt{hg-replay} script in the
+%\texttt{examples} directory works, but doesn't handle merge
+%changesets.  Kind of an important omission.
 
-\subsection{Protect yourself from ``escaped'' changes}
+XXX 追記の必要性あり．\texttt{examples}ディレクトリ内の
+\texttt{hg-replay}スクリプトは機能するが，チェンジセットのマージを扱わな
+い．重要な制限である．
+
+
+%\subsection{Protect yourself from ``escaped'' changes}
+\subsection{逸脱した変更から自分自身を守る}
 
-If you've committed some changes to your local repository and they've
-been pushed or pulled somewhere else, this isn't necessarily a
-disaster.  You can protect yourself ahead of time against some classes
-of bad changeset.  This is particularly easy if your team usually
-pulls changes from a central repository.
+%If you've committed some changes to your local repository and they've
+%been pushed or pulled somewhere else, this isn't necessarily a
+%disaster.  You can protect yourself ahead of time against some classes
+%of bad changeset.  This is particularly easy if your team usually
+%pulls changes from a central repository.
+
+ローカルリポジトリにいくつかの変更をコミットし，それらが別の所にプッシュ
+またはプルされていて，必ずしも大災害とは言えない．あなたはいくつかのクラ
+スの間違った変更から自分自身でみを守ることができる．これはあなたのチーム
+が中央のリポジトリから変更をプルしている場合は特に簡単である．
 
-By configuring some hooks on that repository to validate incoming
-changesets (see chapter~\ref{chap:hook}), you can automatically
-prevent some kinds of bad changeset from being pushed to the central
-repository at all.  With such a configuration in place, some kinds of
-bad changeset will naturally tend to ``die out'' because they can't
-propagate into the central repository.  Better yet, this happens
-without any need for explicit intervention.
+%By configuring some hooks on that repository to validate incoming
+%changesets (see chapter~\ref{chap:hook}), you can automatically
+%prevent some kinds of bad changeset from being pushed to the central
+%repository at all.  With such a configuration in place, some kinds of
+%bad changeset will naturally tend to ``die out'' because they can't
+%propagate into the central repository.
+%Better yet, this happens without any need for explicit intervention.
 
-For instance, an incoming change hook that verifies that a changeset
-will actually compile can prevent people from inadvertantly ``breaking
-the build''.
+中央リポジトリの上で，変更到着にフックを設定する（\ref{chap:hook}を参照）
+ことで，ある種の誤ったチェンジセットが中央リポジトリにコミットされるのを
+自動的に防ぐことができる．
+そのような設定を行うことで，ある種の誤ったチェンジセットはセントラルリポ
+ジトリに波及することができず，死滅していく傾向がある．さらに良いこととし
+ては，これは明示的に介入せずに発生させることができることがある．
+
+%For instance, an incoming change hook that verifies that a changeset
+%will actually compile can prevent people from inadvertantly ``breaking
+%the build''.
+
+例えば，チェンジセットを実際にコンパイルする変更到着フックは，不注意によ
+るビルド不能を防ぐことができる．
 
 \section{Finding the source of a bug}
 \label{sec:undo:bisect}