# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1245543647 -32400
# Node ID de41429834452d0b45b0de2efa90dbec5d70f582
# Parent  ce4050cf7d44090982c8ccfee794ed17c0842d0d
Propagate 3b640272a966

Progres on resolve

diff -r ce4050cf7d44 -r de4142983445 ja/collab.tex
--- a/ja/collab.tex	Thu Jun 18 20:12:07 2009 +0900
+++ b/ja/collab.tex	Sun Jun 21 09:20:47 2009 +0900
@@ -34,7 +34,7 @@
 
 %Also for human consumption, the web interface provides an RSS feed of
 %the changes in a repository.  This lets you ``subscribe'' to a
-%repository using your favourite feed reader, and be automatically
+%repository using your favorite feed reader, and be automatically
 %notified of activity in that repository as soon as it happens.  I find
 %this capability much more convenient than the model of subscribing to
 %a mailing list to which notifications are sent, as it requires no
@@ -161,7 +161,7 @@
 
 %As one example, many projects have a loose-knit group of collaborators
 %who rarely physically meet each other.  Some groups like to overcome
-%the isolation of working at a distance by organising occasional
+%the isolation of working at a distance by organizing occasional
 %``sprints''.  In a sprint, a number of people get together in a single
 %location (a company's conference room, a hotel meeting room, that kind
 %of place) and spend several days more or less locked in there, hacking
@@ -407,7 +407,7 @@
 %\subsection{The release train}
 \subsection{リリーストレイン}
 
-%Some projects are organised on a ``train'' basis: a release is
+%Some projects are organized on a ``train'' basis: a release is
 %scheduled to happen every few months, and whatever features are ready
 %when the ``train'' is ready to leave are allowed in.
 
diff -r ce4050cf7d44 -r de4142983445 ja/daily.tex
--- a/ja/daily.tex	Thu Jun 18 20:12:07 2009 +0900
+++ b/ja/daily.tex	Sun Jun 21 09:20:47 2009 +0900
@@ -26,20 +26,20 @@
 
 %After you run a \hgcmd{commit}, the files that you added before the
 %commit will no longer be listed in the output of \hgcmd{status}.  The
-%reason for this is that \hgcmd{status} only tells you about
-%``interesting'' files---those that you have modified or told Mercurial
-%to do something with---by default.  If you have a repository that
-%contains thousands of files, you will rarely want to know about files
-%that Mercurial is tracking, but that have not changed.  (You can still
-%get this information; we'll return to this later.)
+%reason for this is that by default, \hgcmd{status} only tells you about
+%``interesting'' files---those that you have (for example) modified,
+%removed, or renamed. If you have a repository that contains thousands of
+%files, you will rarely want to know about files that Mercurial is
+%tracking, but that have not changed.  (You can still get this
+%information; we'll return to this later.)
 
 \hgcmd{commit}コマンドを実行すると，commitの前に追加したファイルは
 \hgcmd{status}の出力に現れなくなる．これは，\hgcmd{status}がデフォルトで
-は変更を加えたり，Mercurialに何かをさせたといった``注目すべき''ファイルの
-みを表示するためである．数千のファイルからなるリポジトリの場合，Mercurialが
-追跡しているものの，変更の加えられていないファイルについて何かを知りたい
-ということは稀である．（もちろん知りたい場合は情報を得ることもできる．こ
-れについては後述する．）
+は，変更，削除，リネームなどを行った``注目すべき''ファイルのみを表示する
+ためである．数千のファイルからなるリポジトリの場合，Mercurialが追跡してい
+るものの，変更の加えられていないファイルについて何かを知りたいということ
+は稀である．（もちろん知りたい場合は情報を得ることもできる．これについて
+は後述する．）
 
 %Once you add a file, Mercurial doesn't do anything with it
 %immediately.  Instead, it will take a snapshot of the file's state the
@@ -61,23 +61,23 @@
 %\interaction{daily.files.add-dir}
 %Notice in this example that Mercurial printed the names of the files
 %it added, whereas it didn't do so when we added the file named
-%\filename{a} in the earlier example.
+%\filename{myfile.txt} in the earlier example.
 
 Mercurialの全てのコマンドは，引数としてディレクトリ名を渡すと，ディレクト
 リの内の全てのファイルとサブディレクトリに対する操作であると解釈するため
 便利である．
 \interaction{daily.files.add-dir}
 この例ではMercurialは追加したファイル名を表示しているが，前の例で
-\filename{a}という名前のファイルを追加した際には表示していなかった点に注
-意されたい．
+\filename{myfile.txt}という名前のファイルを追加した際には表示していなかっ
+た点に注意されたい．
 
-%What's going on is that in the former case, we explicitly named the
-%file to add on the command line, so the assumption that Mercurial
-%makes in such cases is that you know what you were doing, and it
-%doesn't print any output.
+%What's going on is that in the former case, we explicitly named the file
+%to add on the command line. The assumption that Mercurial makes in such
+%cases is that we know what we are doing, and it doesn't print any
+%output.
 
-前の例ではコマンドラインでどのファイルを追加するのかを明示的に指定したた
-め，Mercurialはユーザが何をしようとしているのか分かっていると推定して何も
+前の例では，コマンドラインで追加するファイルを明示的に指定したた
+め，Mercurialはユーザが何をしようとしているのか分かっていると推定し，何も
 表示しなかった．
 
 %However, when we \emph{imply} the names of files by giving the name of
@@ -151,7 +151,7 @@
 \section{ファイル追跡の停止}
 
 %Once you decide that a file no longer belongs in your repository, use
-%the \hgcmd{remove} command; this deletes the file, and tells Mercurial
+%the \hgcmd{remove} command. This deletes the file, and tells Mercurial
 %to stop tracking it.  A removed file is represented in the output of
 %\hgcmd{status} with a ``\texttt{R}''.
 %\interaction{daily.files.remove}
@@ -193,17 +193,18 @@
 %the file.
 ファイルをどのように削除してもファイルの\emph{履歴}は変更\emph{されない}．
 
-%If you update the working directory to a changeset in which a file
-%that you have removed was still tracked, it will reappear in the
-%working directory, with the contents it had when you committed that
-%changeset.  If you then update the working directory to a later
-%changeset, in which the file had been removed, Mercurial will once
+%If you update the working directory to a changeset that was committed
+%when it was still tracking a file that you later removed, the file will
+%reappear in the working directory, with the contents it had when you
+%committed that changeset.  If you then update the working directory to a
+%later changeset, in which the file had been removed, Mercurial will once
 %again remove the file from the working directory.
 
-ワーキングディレクトリを，消去したファイルを含むチェンジセットに更新する
-と，ファイルはそのチェンジセットでの内容で再びワーキングディレクトリに現
-れる．そこでファイルが消去されている後のチェンジセットに更新する
-と，Mercurialはファイルを再びワーキングディレクトリから消去する．
+ワーキングディレクトリを，消去したファイルが管理されていた頃にコミットさ
+れたチェンジセットに更新すると，ファイルはそのチェンジセットのコミット時
+の内容でワーキングディレクトリに再び現れる．そこでワーキングディレクトリ
+をファイルの消去された後のチェンジセットに更新すると，Mercurialは再びファ
+イルをワーキングディレクトリから消去する．
 
 %\subsection{Missing files}
 \subsection{欠落したファイル}
@@ -355,8 +356,8 @@
 \subsection{変更はなぜコピーに従わなければならないか}
 \label{sec:daily:why-copy}
 
-%This behaviour, of changes to a file propagating out to copies of the
-%file, might seem esoteric, but in most cases it's highly desirable.
+%This behaviour---of changes to a file propagating out to copies of the
+%file---might seem esoteric, but in most cases it's highly desirable.
 
 ファイルへの変更がそのコピーへ波及する動作は難解に思えるかもしないが，多
 くの場合は非常に望ましい動作である．
@@ -370,12 +371,12 @@
 を\hgcmd{copy}する場合や，通常の作業でオリジナルファイルを変更する場合は
 何も起きない．
 
-%The second thing to know is thatmodifications will only propagate
-%across a copy as long as the repository that you're pulling changes
-%from \emph{doesn't know} about the copy.
+%The second thing to know is that modifications will only propagate
+%across a copy as long as the changeset that you're merging changes from
+%\emph{hasn't yet seen} the copy.
 
-知っておくべき点の2つ目は，変更をpullするリポジトリが，コピーについて
-\emph{関知しない}限り，変更は波及するということである．
+知っておくべき点の2つ目は，変更は変更のマージ元のチェンジセットがコピーを
+\emph{関知していない場合}にのみ波及するということである．
 
 %The reason that Mercurial does this is as follows.  Let's say I make
 %an important bug fix in a source file, and commit my changes.
@@ -389,13 +390,13 @@
 \hgcmd{copy}を行い，ファイルの変更を始めたとする．
 
 %If you pulled and merged my changes, and Mercurial \emph{didn't}
-%propagate changes across copies, your source file would now contain
-%the bug, and unless you remembered to propagate the bug fix by hand,
-%the bug would \emph{remain} in your copy of the file.
+%propagate changes across copies, your new source file would now contain
+%the bug, and unless you knew to propagate the bug fix by hand, the bug
+%would \emph{remain} in your copy of the file.
 
 あなたが私の行った変更をpullし，mergeした場合，Mercurialは変更をコピー間
-で波及させない．あなたのソースファイル今バグを持っているかもしれないが，
-バグ修正を手で波及させなければバグはファイルのコピーに\emph{残る}．
+で波及させない．あなたの新しいソースファイルは今バグを持っているかもしれ
+ないが，バグ修正を手で波及させなければバグはファイルのコピーに\emph{残る}．
 
 %By automatically propagating the change that fixed the bug from the
 %original file to the copy, Mercurial prevents this class of problem.
@@ -407,16 +408,15 @@
 り，Mercurialは，このようなコピー間で変更を波及させる唯一のリビジョンコン
 トロールシステムである．
 
-%Once your change history has a record that the copy and subsequent
-%merge occurred, there's usually no further need to propagate changes
-%from the original file to the copied file, and that's why Mercurial
-%only propagates changes across copies until this point, and no
-%further.
+%Once your change history has a record that the copy and subsequent merge
+%occurred, there's usually no further need to propagate changes from the
+%original file to the copied file, and that's why Mercurial only
+%propagates changes across copies at the first merge, and not afterwards.
 
 コピーと後続のマージが起こったことが更新履歴に含まれる場合，変更をオリジ
 ナルファイルからコピーされたファイルへさらに波及させる必要はない．これが
-Mercurialがこの時点までのみ変更をコピー間で波及させ，その後では行わない理
-由である．
+Mercurialが最初のマージの時にコピー間で変更を波及させ，その後では行わない
+理由である．
 
 %\subsection{How to make changes \emph{not} follow a copy}
 \subsection{変更がコピーに従わないようにする方法}
@@ -427,7 +427,7 @@
 %\command{cp}) to make a copy of a file, then \hgcmd{add} the new copy
 %by hand.  Before you do so, though, please do reread
 %section~\ref{sec:daily:why-copy}, and make an informed decision that
-%this behaviour is not appropriate to your specific case.
+%this behavior is not appropriate to your specific case.
 
 何らかの理由でこのように変更が自動的に波及するやり方が好ましくないと思わ
 れる場合は，システム標準のあファイルコピーコマンド（UNIX系システムでは
@@ -436,7 +436,7 @@
 に，~\ref{sec:daily:why-copy}節を再読し，このやり方の詳細を踏まえた上で，
 あなたのケースに適しているか判断してほしい．
 
-%\subsection{Behaviour of the \hgcmd{copy} command}
+%\subsection{Behavior of the \hgcmd{copy} command}
 \subsection{\hgcmd{copy}コマンドの挙動}
 
 %When you use the \hgcmd{copy} command, Mercurial makes a copy of each
@@ -453,11 +453,21 @@
 加えた変更を含んでいる． （筆者はこの挙動はやや直観に反すると考えているた
 め，敢えてここで言及した．）
 
-%The \hgcmd{copy} command acts similarly to the Unix \command{cp}
-%command (you can use the \hgcmd{cp} alias if you prefer).  The last
-%argument is the \emph{destination}, and all prior arguments are
-%\emph{sources}.  If you pass it a single file as the source, and the
+%The \hgcmd{copy} command acts similarly to the Unix \command{cp} command
+%(you can use the \hgcmd{cp} alias if you prefer). We must supply two or
+%more arguments, of which the last is treated as the \emph{destination},
+%and all others are \emph{sources}.
+
+\hgcmd{copy}コマンドはUnixの\command{cp}と同様に振舞う．（\hgcmd{cp}エイ
+リアスを定義して使うことも可能だ．）引数は2つ以上が必要で，最後の引数は
+\emph{コピー先}で，それ以外の引数は\emph{コピー元}として扱われる．
+
+%If you pass \hgcmd{copy} a single file as the source, and the
 %destination does not exist, it creates a new file with that name.
+
+コピー元として単一のファイルを指定し，コピー先ファイルが存在しない場合，
+コマンドはコピー先ファイルを新規に作成する．
+
 %\interaction{daily.copy.simple}
 %If the destination is a directory, Mercurial copies its sources into
 %that directory.
@@ -469,11 +479,6 @@
 %recreated in the destination directory.
 %\interaction{daily.copy.dir-src-dest}
 
-\hgcmd{copy}コマンドはUnixの\command{cp}と同様に振舞う．（\hgcmd{cp}エイ
-リアスを定義して使うことも可能だ．）引数の最後は\emph{コピー先}で，それ以
-前の引数は\emph{コピー元}である．コピー元として単一のファイルを指定し，コ
-ピー先ファイルが存在しない場合，コマンドはコピー先ファイルを新規に作成す
-る．
 \interaction{daily.copy.simple}
 コピー先がディレクトリの場合，Mercurialはコピー元をコピー先ディレクトリ
 の中にコピーする．
@@ -484,12 +489,12 @@
 先のディレクトリの中に再現される．
 \interaction{daily.copy.dir-src-dest}
 
-%As with the \hgcmd{rename} command, if you copy a file manually and
+%As with the \hgcmd{remove} command, if you copy a file manually and
 %then want Mercurial to know that you've copied the file, simply use
 %the \hgopt{copy}{--after} option to \hgcmd{copy}.
 %\interaction{daily.copy.after}
 
-\hgcmd{rename}コマンドと同様に，ファイルを手動でコピーした後で，Mercurialに
+\hgcmd{remove}コマンドと同様に，ファイルを手動でコピーした後で，Mercurialに
 操作を通知したい場合は，\hgcmd{copy}コマンドに\hgopt{copy}{--after}オプ
 ションを付ければよい．
 \interaction{daily.copy.after}
@@ -545,6 +550,12 @@
 マンドの挙動と，このコマンドが受け入れるオプションは\hgcmd{copy}コマンド
 と類似している．
 
+%If you're familiar with the Unix command line, you'll be glad to know
+%that \hgcmd{rename} command can be invoked as \hgcmd{mv}.
+
+Unixコマンドに慣れているなら，\hgcmd{rename}の代わりに\hgcmd{mv}が使える
+ことを知っているとよいだろう．
+
 %\subsection{Renaming files and merging changes}
 \subsection{ファイルのリネームと変更のマージ}
 
@@ -592,15 +603,15 @@
 %Anne renames the file to \filename{bar}.
 アンはファイルを\filename{bar}と改名した．
 \interaction{rename.divergent.rename.anne}
-%Meanwhile, Bob renames it to \filename{quux}.
-その間，ボブは同じファイルを\filename{quux}と改名した．
+%Meanwhile, Bob renames it to \filename{quux}. (Remember that \hgcmd{mv}
+%is an alias for \hgcmd{rename}.)
+その間，ボブは同じファイルを\filename{quux}と改名した．（\hgcmd{mv}が
+\hgcmd{rename}のエイリアスであることに注意）
 \interaction{rename.divergent.rename.bob}
-
 %I like to think of this as a conflict because each developer has
 %expressed different intentions about what the file ought to be named.
-
-各々の開発者はファイルがどのように呼ばれるべきかについて異なった意図を持っ
-ており，これはコンフリクトと考えられる．
+各々の開発者はファイルが何と呼ばれるべきか異なった意見を持っており，これ
+は名前のコンフリクトである．
 
 %What do you think should happen when they merge their work?
 %Mercurial's actual behaviour is that it always preserves \emph{both}
@@ -612,8 +623,8 @@
 名前を保存する．
 \interaction{rename.divergent.merge}
 
-%Notice that Mercurial does warn about the divergent renames, but it
-%leaves it up to you to do something about the divergence after the merge.
+%Notice that while Mercurial warns about the divergent renames, it leaves
+%it up to you to do something about the divergence after the merge.
 
 Mercurialは名前の発散について警告するが，マージ後も名前の発散の解決はユー
 ザに任せる点に注意．
@@ -663,7 +674,7 @@
 \hgcmd{revert}を実行すればファイルは何も変更されず，Mercurialの管理から外
 される．また\hgcmd{revert}はファイルへの間違った変更を消去するのも使える．
 
-%It's useful to remember that the \hgcmd{revert} command is useful for
+%It's good to remember that the \hgcmd{revert} command is useful for
 %changes that you have not yet committed.  Once you've committed a
 %change, if you decide it was a mistake, you can still do something
 %about it, though your options may be more limited.
@@ -679,6 +690,176 @@
 \hgcmd{revert}コマンドについてのより詳細な情報と，すでにコミットした変更
 への操作については~\ref{chap:undo}の章を参照されたい．
 
+%\section{Dealing with tricky merges}
+\section{複雑なマージの取り扱い}
+
+%In a complicated or large project, it's not unusual for a merge of two
+%changesets to result in some headaches.  Suppose there's a big source
+%file that's been extensively edited by each side of a merge: this is
+%almost inevitably going to result in conflicts, some of which can take a
+%few tries to sort out.
+
+複雑なプロジェクトや大規模なプロジェクトでは， 2つのチェンジセットをマー
+ジする時に頭を悩ませることが少なくない．マージ元の双方で盛んに編集されて
+いる大きなソースファイルがあるとすると，コンフリクトが生じることはほぼ不
+可避であり，収拾するためには少々手数がかかる．
+
+%Let's develop a simple case of this and see how to deal with it.  We'll
+%start off with a repository containing one file, and clone it
+%twice.
+
+このような場合について，簡単な例で解決方法をを見てみよう．まず，ファイル
+1つのみを含むリポジトリを作り，これを二度クローンする．
+
+%\interaction{ch04-resolve.init}
+
+%In one clone, we'll modify the file in one way.
+
+クローンの一方でファイルを変更する．
+
+%\interaction{ch04-resolve.left}
+
+%In another, we'll modify the file differently.
+
+もう一方のクローンでも別の変更を行う．
+
+%\interaction{ch04-resolve.right}
+
+%Next, we'll pull each set of changes into our original repo.
+
+次に元のリポジトリに各々の変更をpullする．
+
+%\interaction{ch04-resolve.pull}
+
+%We expect our repository to now contain two heads.
+
+元のリポジトリには今ヘッドが2つある．
+
+%\interaction{ch04-resolve.heads}
+
+%Normally, if we run \hgcmd{merge} at this point, it will drop us into a
+%GUI that will let us manually resolve the conflicting edits to
+
+%\filename{myfile.txt}.  However, to simplify things for presentation
+%here, we'd like the merge to fail immediately instead.  Here's one way
+%we can do so.
+
+通常の場合，ここで\hgcmd{merge}を実行すると，ファイル
+\filename{myfile.txt}のコンフリクトを手動で解決するためのGUIが起動する．
+しかしここでは説明を単純にするために，直ちに失敗するマージをしてみよう．
+その方法はこのようになる．
+
+%\interaction{ch04-resolve.export}
+
+%We've told Mercurial's merge machinery to run the command
+%\command{false} (which, as we desire, fails immediately) if it detects a
+%merge that it can't sort out automatically.
+
+自動的に片付かないマージが見つかった場合は，Mercurialのマージメカニズムが
+\command{false}コマンド（これは希望通り直ちに失敗する．）を実行するよう
+にさせる．
+
+%If we now fire up \hgcmd{merge}, it should grind to a halt and report a
+%failure.
+
+ここで\hgcmd{merge}を実行すると，実行は停止して，マージの失敗が報告され
+る．
+
+%\interaction{ch04-resolve.merge}
+
+%Even if we don't notice that the merge failed, Mercurial will prevent us
+%from accidentally committing the result of a failed merge.
+
+ユーザがマージの失敗に気付かない場合でも，Mercurialは自動的に失敗したマー
+ジの結果のコミットを妨げる．
+
+%\interaction{ch04-resolve.cifail}
+
+%When \hgcmd{commit} fails in this case, it suggests that we use the
+%unfamiliar \hgcmd{resolve} command.  As usual, \hgcmd{help resolve} will
+%print a helpful synopsis.
+
+\hgcmd{commit}が失敗すると，あまり馴染みのないコマンドである
+\hgcmd{resolve}を使うようにメッセージが表示される．このコマンドの使用法は
+いつも通り\hgcmd{help resolve}を実行することで見ることができる．
+
+%\subsection{File resolution states}
+\subsection{ファイル解決状態}
+
+%When a merge occurs, most files will usually remain unmodified.  For
+%each file where Mercurial has to do something, it tracks the state of
+%the file.
+
+マージの際にほとんどのファイルはそのまま残される．Mercurialは操作を行うファ
+イルの状態を管理している．
+
+\begin{itemize}
+% \item A \emph{resolved} file has been successfully merged, either
+%       automatically by Mercurial or manually with human intervention.
+ \item \emph{解決済み}ファイルはマージが成功したファイルで，Mercurialに
+       よって自動的に行われたか，人がマージ作業を行ったかは問わない．
+% \item An \emph{unresolved} file was not merged successfully, and needs
+%       more attention.
+ \item \emph{未解決}ファイルはマージが失敗し，なんらかの修正が必要な
+       ファイルである．
+\end{itemize}
+
+%If Mercurial sees \emph{any} file in the unresolved state after a merge,
+%it considers the merge to have failed.  Fortunately, we do not need to
+%restart the entire merge from scratch.
+
+Mercurialはマージ後に未解決状態のファイルを見つけると，マージが失敗
+したと判断する．幸いなことにこの場合でもマージを始めからやり直す必要はな
+い．
+
+%The \hgopt{resolve}{--list} or \hgopt{resolve}{-l} option to
+%\hgcmd{resolve} prints out the state of each merged file.
+
+\hgcmd{resolve}コマンドで\hgopt{resolve}{--list}オプションや
+\hgopt{resolve}{-l}オプションを使うと，マージされた各々のファイルの状態
+が表示される．
+
+%\interaction{ch04-resolve.list}
+
+%In the output from \hgcmd{resolve}, a resolved file is marked with
+%\texttt{R}, while an unresolved file is marked with \texttt{U}.  If any
+%files are listed with \texttt{U}, we know that an attempt to commit the
+%results of the merge will fail.
+
+\hgcmd{resolve}の出力で，解決済みファイルは\texttt{R}，未解決のファイル
+は\texttt{U}と表される．\texttt{U}となるファイルがある場合，マージ結果の
+コミットは失敗する．
+
+%\subsection{Resolving a file merge}
+\subsection{ファイルマージの解決}
+
+%We have several options to move a file from the unresolved into the
+%resolved state.  By far the most common is to rerun \hgcmd{resolve}.  If
+%we pass the names of individual files or directories, it will retry the
+%merges of any unresolved files present in those locations. We can also
+%pass the \hgopt{resolve}{--all} or \hgopt{resolve}{-a} option, which
+%will retry the merges of \emph{all} unresolved files.
+
+ファイルを未解決状態から解決済み状態へ持っていく方法はいくつかあ
+る．最もよく用いられるのが再度\hgcmd{resolve}を実行する方法である．このコ
+マンドは各々のファイルやディレクトリの名前を渡すと，未解決のファイル
+に対してマージを再度試みる． \hgopt{resolve}{--all}または
+\hgopt{resolve}{-a}オプションを渡して\emph{全ての}未解決ファイルに対
+して再マージを行うこともできる．
+
+%Mercurial also lets us modify the resolution state of a file directly.
+%We can manually mark a file as resolved using the
+%\hgopt{resolve}{--mark} option, or as unresolved using the
+%\hgopt{resolve}{--unmark} option.  This allows us to clean up a
+%particularly messy merge by hand, and to keep track of our progress with
+%each file as we go.
+
+Mercurialによってファイルの解決状態を直接変更することも可能だ．
+\hgopt{resolve}{--mark}オプションを使うことで，ファイルを解決済みとマー
+クしたり，逆に\hgopt{resolve}{--unmark}オプションで未解決とマークする
+こともできる．これらによって混乱したマージを手動で整理して，作業を続ける
+ことができる．
+
 %%% Local Variables:
 %%% mode: yatex
 %%% TeX-master: "00book"
diff -r ce4050cf7d44 -r de4142983445 ja/examples/ch04/resolve
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ja/examples/ch04/resolve	Sun Jun 21 09:20:47 2009 +0900
@@ -0,0 +1,38 @@
+#$ name: init
+hg init conflict
+cd conflict
+echo first > myfile.txt
+hg ci -A -m first
+cd ..
+hg clone conflict left
+hg clone conflict right
+
+#$ name: left
+cd left
+echo left >> myfile.txt
+hg ci -m left
+
+#$ name: right
+cd ../right
+echo right >> myfile.txt
+hg ci -m right
+
+#$ name: pull
+cd ../conflict
+hg pull -u ../left
+hg pull -u ../right
+
+#$ name: heads
+hg heads
+
+#$ name: export
+export HGMERGE=merge
+
+#$ name: merge
+hg merge
+
+#$ name: cifail
+hg commit -m 'Attempt to commit a failed merge'
+
+#$ name: list
+hg resolve -l
diff -r ce4050cf7d44 -r de4142983445 ja/mq.tex
--- a/ja/mq.tex	Thu Jun 18 20:12:07 2009 +0900
+++ b/ja/mq.tex	Sun Jun 21 09:20:47 2009 +0900
@@ -1634,7 +1634,7 @@
 %Whether you are working on a patch series to submit to a free software
 %or open source project, or a series that you intend to treat as a
 %sequence of regular changesets when you're done, you can use some
-%simple techniques to keep your work well organised.
+%simple techniques to keep your work well organized.
 
 フリーソフトやオープンソースプロジェクトに提出するためのパッチシリーズに
 対して作業しているときや，作業が終ったときに通常のチェンジセットとして取
diff -r ce4050cf7d44 -r de4142983445 ja/tour-basic.tex
--- a/ja/tour-basic.tex	Thu Jun 18 20:12:07 2009 +0900
+++ b/ja/tour-basic.tex	Sun Jun 21 09:20:47 2009 +0900
@@ -739,7 +739,7 @@
 \subsubsection{Mercurialの設定ファイルを作成する}
 \label{sec:tour-basic:username}
 
-%To set a user name, use your favourite editor to create a file called
+%To set a user name, use your favorite editor to create a file called
 %\sfilename{.hgrc} in your home directory.  Mercurial will use this
 %file to look up your personalised configuration settings.  The initial
 %contents of your \sfilename{.hgrc} should look like this.