# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1244011268 -32400
# Node ID 43556decb81ff3d53c826c27e9944dd5872d850b
# Parent  93d19b27859c55f5bab59f84d9ba8b9b95ed4634
finished concepts.tex

diff -r 93d19b27859c -r 43556decb81f ja/concepts.tex
--- a/ja/concepts.tex	Tue May 12 17:49:11 2009 +0900
+++ b/ja/concepts.tex	Wed Jun 03 15:41:08 2009 +0900
@@ -162,7 +162,7 @@
 %The underpinnings of changelogs, manifests, and filelogs are provided
 %by a single structure called the \emph{revlog}.
 
-チェンジログ，マニフェスト，ファイルログの土台に使われているは共通の
+チェンジログ，マニフェストおよびファイルログの土台に使われているは共通の
 \emph{revlog}という構造体である．
 
 %\subsection{Efficient storage}
@@ -281,16 +281,6 @@
 スファイルのエントリに特定のリビジョンを再現するのに必要なデータファイル
 内のある範囲のエントリを保存する．
 
-
-
-
-
-
-
-
-
-
-
 %\subsubsection{Aside: the influence of video compression}
 \subsubsection{その他: ビデオ圧縮の影響}
 
@@ -302,6 +292,12 @@
 %visual errors accumulate over the course of a number of inter-frame
 %deltas.
 
+ビデオ圧縮に慣れていたり，デジタルによるケーブルまたは衛星放送に慣れてい
+るのなら，大部分のビデオ圧縮の仕組みでは，ビデオの各フレームが，前のフレー
+ムとの差分として保存されていることを知っているだろう．加えて，これらの仕
+組みは圧縮率を稼ぐために不可逆な圧縮技術を使っており，映像のエラーはフレー
+ム間の差分が増えるに従って蓄積していく．
+
 %Because it's possible for a video stream to ``drop out'' occasionally
 %due to signal glitches, and to limit the accumulation of artefacts
 %introduced by the lossy compression process, video encoders
@@ -311,6 +307,13 @@
 %the next key frame is received.  Also, the accumulation of encoding
 %errors restarts anew with each key frame.
 
+ビデオストリームでは，信号の不具合によって時折ドロップアウトが出ることが
+あり，また不可逆圧縮による影響の蓄積を抑えるため，ビデオエンコーダは定期
+的に（キーフレームと呼ばれる）完全なフレームをストリームに挿入する．次の
+差分はこのフレームに対して取られる．これによって，ビデオ信号が途絶えても
+次のキーフレームを受信すれば正常に戻ることができる．またエンコードエラー
+の蓄積はキーフレームごとに除去される．
+
 %\subsection{Identification and strong integrity}
 \subsection{識別と強い一貫性}
 
@@ -319,17 +322,31 @@
 %difficult to forge the contents of a revision, and easy to detect
 %accidental corruption.
 
+差分やスナップショット情報と共に，revlogエントリはデータの暗号ハッシュ
+を持つ．ハッシュにより，リビジョンの内容を偽ることが困難になり，また
+事故によって内容が破損した場合，発見が容易になる．
+
 %Hashes provide more than a mere check against corruption; they are
 %used as the identifiers for revisions.  The changeset identification
 %hashes that you see as an end user are from revisions of the
 %changelog.  Although filelogs and the manifest also use hashes,
 %Mercurial only uses these behind the scenes.
 
+ハッシュは単に破損をチェックする以上のことを行う．これらはリビジョンの識
+別にも用いられる．チェンジセットの識別ハッシュは，エンドユーザからはチェ
+ンジログでユーザ名と共に現れる数字として目にすることが多いだろう．
+ファイルログとマニフェストでもハッシュは使われているが，Mercurialはこれ
+らを背後でのみ用いる．
+
 %Mercurial verifies that hashes are correct when it retrieves file
 %revisions and when it pulls changes from another repository.  If it
 %encounters an integrity problem, it will complain and stop whatever
 %it's doing.
 
+Mercurialはファイルのリビジョン取得時と変更を別のリポジトリからpullする時
+にハッシュが正しいことを確認する．一貫性に問題があると，エラーメッセージ
+を出力し，動作を停止する．
+
 %In addition to the effect it has on retrieval efficiency, Mercurial's
 %use of periodic snapshots makes it more robust against partial data
 %corruption.  If a revlog becomes partly corrupted due to a hardware
@@ -338,6 +355,13 @@
 %after the corrupted section.  This would not be possible with a
 %delta-only storage model.
 
+取得の効率に加えて，Mercurialは周期的にスナップショットを使うことで，部分
+的なデータの破損に対して頑強になっている．ハードウェアの問題やシステムの
+バグでrevlogが部分的に破損した場合でも，多くの場合，revlogの破損していな
+い部分から破損した部分の前後でいくつかのリビジョンや大半のリビジョンを再
+建することができる．差分のみを記録するシステムではこれを実現することはで
+きない．
+
 %\section{Revision history, branching, and merging}
 \section{リビジョン履歴，ブランチ，マージ}
 
@@ -347,11 +371,21 @@
 %a special hash, called the ``null ID'', to represent the idea ``there
 %is no parent here''.  This hash is simply a string of zeroes.
 
+Mercurial revlogのすべてのエントリは，通常\emph{parent}として参照される直
+接の祖先のリビジョンを知っている．実際には，リビジョンは1つだけでなく2つ
+の親を記録することができる．Mercurialは``null ID''という特別なハッシュを
+使って``ここには親になるリビジョンがない''ということを表現する．このハッ
+シュは単にゼロを並べた文字列である．
+
 %In figure~\ref{fig:concepts:revlog}, you can see an example of the
 %conceptual structure of a revlog.  Filelogs, manifests, and changelogs
 %all have this same structure; they differ only in the kind of data
 %stored in each delta or snapshot.
 
+revlogの概念的な構造の一例を図~\ref{fig:concepts:revlog}に示す．ファイル
+ログ，マニフェストおよびチェンジログはすべて同じ構造を持つ．これらの違い
+は，各々の差分やスナップショットに格納するデータの違いだけである．
+
 %The first revision in a revlog (at the bottom of the image) has the
 %null ID in both of its parent slots.  For a ``normal'' revision, its
 %first parent slot contains the ID of its parent revision, and its
@@ -360,6 +394,12 @@
 %branches.  A revision that represents a merge between branches has two
 %normal revision IDs in its parent slots.
 
+revlogでの最初のリビジョン（図の一番下）はnull IDを両親を示すスロットの
+両方に持ち，このリビジョンが実際にはただ一つの親しか持たないことを表して
+いる．同じ親のIDを持つ任意の2つのリビジョンはブランチである．
+ブランチ間のマージを表すリビジョンは，2つのノーマルリビジョンIDを両親の
+スロットに持つ．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{revlog}
@@ -373,6 +413,9 @@
 %In the working directory, Mercurial stores a snapshot of the files
 %from the repository as of a particular changeset.
 
+Mercurialはリポジトリのある特定のチェンジセットのファイルスナップショット
+をワーキングディレクトリ内に持つ．
+
 %The working directory ``knows'' which changeset it contains.  When you
 %update the working directory to contain a particular changeset,
 %Mercurial looks up the appropriate revision of the manifest to find
@@ -381,11 +424,23 @@
 %recreates a copy of each of those files, with the same contents it had
 %when the changeset was committed.
 
+ワーキングディレクトリがどのチェンジセットに更新されているがあるのかは既
+知である．ワーキングディレクトリが特定のチェンジセットになるように更新す
+る際， Mercurialは適切なリビジョンのマニフェストを検索し，そのチェンジセッ
+トがコミットされた時点でどのファイルが追跡されているかを調べ，各々のファ
+イルのリビジョンを特定する．そしてチェンジセットがコミットされた時点の内
+容をもつファイルのコピーを作成する．
+
 %The \emph{dirstate} contains Mercurial's knowledge of the working
 %directory.  This details which changeset the working directory is
 %updated to, and all of the files that Mercurial is tracking in the
 %working directory.
 
+\emph{dirstate}にはワーキングディレクトリについてMercurialが把握している
+情報が格納されている．その内容はワーキングディレクトリがアップデートされ
+ているチェンジセットおよびワーキングディレクトリ内でMercurialが追跡してい
+る全てのファイルについての詳細である．
+
 %Just as a revision of a revlog has room for two parents, so that it
 %can represent either a normal revision (with one parent) or a merge of
 %two earlier revisions, the dirstate has slots for two parents.  When
@@ -396,6 +451,14 @@
 %changeset you're merging with.  The \hgcmd{parents} command tells you
 %what the parents of the dirstate are.
 
+revlogにおけるリビジョンが2つの親の情報を格納する領域を持ち，通常のリビジョ
+ン（親は1つ）または2つの親のマージを表現できるのと同様にdirstateも2つの親
+のためのスロットを持っている．\hgcmd{update}コマンドを実行すると，アップ
+デート先のチェンジセットが1つ目の親のスロットに記録され，null IDが2つ目の
+親のスロットに記録される．他のチェンジセットと\hgcmd{merge}を行うと，最初
+の親はそのままに，2番目の親はマージするチェンジセットとな
+る．\hgcmd{parents}コマンドでdirstateの両親を知ることができる．
+
 %\subsection{What happens when you commit}
 \subsection{コミット時に何が起きるのか}
 
@@ -403,6 +466,9 @@
 %purposes.  Mercurial uses the parents of the dirstate as \emph{the
 %  parents of a new changeset} when you perform a commit.
 
+dirstateは管理目的意外の情報も保存している． Mercurialは，コミットの際に
+dirstateの両親を\emph{新たなチェンジセットの両親}として用いる．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{wdir}
@@ -416,6 +482,9 @@
 %is the \emph{tip}, the newest changeset in the repository that has no
 %children.
 
+図~\ref{fig:concepts:wdir}にワーキングディレクトリの通常状態を示す．
+リポジトリの最新のチェンジセットは\emph{tip}で，子を一切持たない．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{wdir-after-commit}
@@ -431,6 +500,12 @@
 %already tracking; the new changeset will have the parents of the
 %working directory as its parents.
 
+ワーキングディレクトリが``コミットしようとしているチェンジセット''である
+と見なすことは役に立つ．追加，削除，リネームまたはコピーしたファイルを
+Mercurialに認識させると，すでにMercurialが追跡している任意のファイルへの
+変更と同様，すべてチェンジセットに反映される．新たなチェンジセットはワー
+キングディレクトリの両親を両親として持つ．
+
 %After a commit, Mercurial will update the parents of the working
 %directory, so that the first parent is the ID of the new changeset,
 %and the second is the null ID.  This is shown in
@@ -438,6 +513,12 @@
 %any of the files in the working directory when you commit; it just
 %modifies the dirstate to note its new parents.
 
+コミット後，Mercurialはワーキングディレクトリの両親を更新し，1つ目の親が
+新たなチェンジセットのID，2番目をnull IDにする．これを
+図~\ref{fig:concepts:wdir-after-commit}に示す．Mercurialはコミット時にワー
+キングディレクトリ内のファイルには一切触れず，dirstateに新たな両親を記録
+する．
+
 %\subsection{Creating a new head}
 \subsection{新たなヘッドを作る}
 
@@ -447,10 +528,19 @@
 %changesets to see which one introduced a bug.  In cases like this, the
 %natural thing to do is update the working directory to the changeset
 %you're interested in, and then examine the files in the working
-%directory directly to see their contents as they werea when you
+%directory directly to see their contents as they were when you
 %committed that changeset.  The effect of this is shown in
 %figure~\ref{fig:concepts:wdir-pre-branch}.
 
+ワーキングディレクトリを現在のtip以外のチェンジセットに更新することはいさ
+さかもおかしなことではない．例えば，この前の火曜日にプロジェクトがどのよ
+うな状態であったか知りたいと思うかもしれないし，チェンジセットのうちのど
+れがバグを混入させたか突き止めたいと考えることがあるかもしれない．このよ
+うな場合，ワーキングディレクトリを興味のあるチェンジセットに更新し，チェ
+ンジセットをコミットした時にそれらがどのようであったかを見るためにワーキ
+ングディレクトリ内のファイルを調べるのが自然である．この影響は
+図~\ref{fig:concepts:wdir-pre-branch}に示す．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{wdir-pre-branch}
@@ -468,6 +558,13 @@
 %\emph{heads}.  You can see the structure that this creates in
 %figure~\ref{fig:concepts:wdir-branch}.
 
+ワーキングディレクトリを古いチェンジセットに更新し，変更を行ってコミット
+すると何が起こるだろうか？ Mercurialは前述のように振舞う．ワーキングディ
+レクトリの両親は新たなチェンジセットの両親となる．新たなチェンジセットは
+子を持たず，従って新たなtipとなる．リポジトリには\emph{heads}と呼ばれる2
+つのチェンジセットができる．この時の構造を
+図~\ref{fig:concepts:wdir-branch}に示す．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{wdir-branch}
@@ -494,6 +591,22 @@
 %  on.
 %\end{note}
 
+\begin{note}
+Mercurialを使い始めたばかりであれば，よくある``エラー''を覚えておくとよ
+い．それは\hgcmd{pull}コマンドをオプションなしで実行することである．デフォ
+ルトでは\hgcmd{pull}はワーキングディレクトリの更新を\emph{行わない}．その
+ため，リポジトリには新しいチェンジセットが到着しているのにワーキングディ
+レクトリは前回pullしたチェンジセットのままである．ここでなんらかの変更を
+行ってコミットしようとすると，ワーキングディレクトリが現在のtipに同期して
+いないため，新たなヘッドを作ることになってしまう．
+
+``エラー''という言葉を引用符で括ったのは，この状態は\hgcmd{merge}と
+\hgcmd{commit}だけで解消できるからだ．言い替えると，この状態はほとんどの
+場合害をなすものではななく，単にユーザを驚かす程度のものである．この振舞
+を避ける別の方法や，なぜMercurialがこのように驚かせるような方法で動作する
+のかについては後ほど議論する．
+\end{note}
+
 %\subsection{Merging heads}
 \subsection{ヘッド間のマージ}
 
@@ -502,6 +615,10 @@
 %to the changeset you're merging with, as shown in
 %figure~\ref{fig:concepts:wdir-merge}.
 
+\hgcmd{merge}コマンドを実行した時，Mercurialはワーキングディレクトリの最
+初の親を変更せず残し，2番目の親を図~\ref{fig:concepts:wdir-merge}のよう
+にマージ先のチェンジセットとする．
+
 \begin{figure}[ht]
   \centering
   \includegraphics{wdir-merge}
@@ -510,79 +627,141 @@
   \label{fig:concepts:wdir-merge}
 \end{figure}
 
-Mercurial also has to modify the working directory, to merge the files
-managed in the two changesets.  Simplified a little, the merging
-process goes like this, for every file in the manifests of both
-changesets.
+%Mercurial also has to modify the working directory, to merge the files
+%managed in the two changesets.  Simplified a little, the merging
+%process goes like this, for every file in the manifests of both
+%changesets.
+
+Mercurialは2つのチェンジセット内で管理されているファイルをマージするため
+にワーキングディレクトリを変更する必要がある．少し単純化すると，マージプ
+ロセスは双方のチェンジセットのマニフェスト内にある全てのファイルに対して
+次のように行われる．
+
 \begin{itemize}
-\item If neither changeset has modified a file, do nothing with that
-  file.
-\item If one changeset has modified a file, and the other hasn't,
-  create the modified copy of the file in the working directory.
-\item If one changeset has removed a file, and the other hasn't (or
-  has also deleted it), delete the file from the working directory.
-\item If one changeset has removed a file, but the other has modified
-  the file, ask the user what to do: keep the modified file, or remove
-  it?
-\item If both changesets have modified a file, invoke an external
-  merge program to choose the new contents for the merged file.  This
-  may require input from the user.
-\item If one changeset has modified a file, and the other has renamed
-  or copied the file, make sure that the changes follow the new name
-  of the file.
+%\item If neither changeset has modified a file, do nothing with that
+%  file.
+ \item どちらのチェンジセットでも変更されていないファイルに対しては何も
+       行わない．
+%\item If one changeset has modified a file, and the other hasn't,
+%  create the modified copy of the file in the working directory.
+ \item 変更されたファイルが片方のチェンジセットに含まれ，もう一方には含
+       まれない場合，ワーキングディレクトリに変更されたコピーが作成され
+       る．
+%\item If one changeset has removed a file, and the other hasn't (or
+%  has also deleted it), delete the file from the working directory.
+ \item 一方のチェンジセットで削除されたファイルがあり，もう一方がそのファ
+       イルを含まないか，同様に削除されている場合はワーキングディレクト
+       リからそのファイルを削除する．
+%\item If one changeset has removed a file, but the other has modified
+%  the file, ask the user what to do: keep the modified file, or remove
+%  it?
+ \item 一方のチェンジセットでファイルが削除されており，もう一方ではその
+       ファイルが変更されている場合は，変更されたファイルを維持するかファ
+       イルを消去するかかユーザに尋ねる．
+%\item If both changesets have modified a file, invoke an external
+%  merge program to choose the new contents for the merged file.  This
+%  may require input from the user.
+ \item 両方のチェンジセットでファイルが変更されている場合，マージ後のファ
+       イルの内容を選択するために外部のマージプログラムを起動する．これ
+       を行うためにはユーザの入力が必要である．
+%\item If one changeset has modified a file, and the other has renamed
+%  or copied the file, make sure that the changes follow the new name
+%  of the file.
+ \item 一方のチェンジセットでファイルが変更されており，もう一方ではファ
+       イルがリネームまたはコピーされている場合，変更は新しい名前のファ
+       イルに取り込まれる．
 \end{itemize}
-There are more details---merging has plenty of corner cases---but
-these are the most common choices that are involved in a merge.  As
-you can see, most cases are completely automatic, and indeed most
-merges finish automatically, without requiring your input to resolve
-any conflicts.
+
+%There are more details---merging has plenty of corner cases---but
+%these are the most common choices that are involved in a merge.  As
+%you can see, most cases are completely automatic, and indeed most
+%merges finish automatically, without requiring your input to resolve
+%any conflicts.
+
+詳しく述べればマージにはいろいろな特殊例がある．しかしここでは最も普通の
+選択について説明する．これまで見てきたように，大半のケースは完全に自動で
+あり，実際に大半のマージは衝突を解決するために入力を求めることなく自動的
+に完了する．
+
+%When you're thinking about what happens when you commit after a merge,
+%once again the working directory is ``the changeset I'm about to
+%commit''.  After the \hgcmd{merge} command completes, the working
+%directory has two parents; these will become the parents of the new
+%changeset.
 
-When you're thinking about what happens when you commit after a merge,
-once again the working directory is ``the changeset I'm about to
-commit''.  After the \hgcmd{merge} command completes, the working
-directory has two parents; these will become the parents of the new
-changeset.
+マージ後にコミットを行うとき何が起こるかを考える場合はやはりワーキングディ
+レクトリを``これからコミットしようとするチェンジセット''と考えるとよい．
+\hgcmd{merge}コマンドが完了した後，ワーキングディレクトリは2つの親を持
+ち，これらは新たなチェンジセットの両親となる．
 
-Mercurial lets you perform multiple merges, but you must commit the
-results of each individual merge as you go.  This is necessary because
-Mercurial only tracks two parents for both revisions and the working
-directory.  While it would be technically possible to merge multiple
-changesets at once, the prospect of user confusion and making a
-terrible mess of a merge immediately becomes overwhelming.
+%Mercurial lets you perform multiple merges, but you must commit the
+%results of each individual merge as you go.  This is necessary because
+%Mercurial only tracks two parents for both revisions and the working
+%directory.  While it would be technically possible to merge multiple
+%changesets at once, the prospect of user confusion and making a
+%terrible mess of a merge immediately becomes overwhelming.
+
+Mercurialは複数回のマージを促す．ここでそれぞれのマージの結果を自分自身で
+コミットしなければならない．これはMercurialがリビジョンとワーキングディレ
+クトリの双方について2つの親のみを追跡することによる．複数のチェンジセット
+を一度にマージすることは技術的には可能だが，マージによる混乱を引き起こ
+し，収拾がつかなくなる見込みが大きい．
 
 %\section{Other interesting design features}
 \section{設計の他の興味深い点}
 
-In the sections above, I've tried to highlight some of the most
-important aspects of Mercurial's design, to illustrate that it pays
-careful attention to reliability and performance.  However, the
-attention to detail doesn't stop there.  There are a number of other
-aspects of Mercurial's construction that I personally find
-interesting.  I'll detail a few of them here, separate from the ``big
-ticket'' items above, so that if you're interested, you can gain a
-better idea of the amount of thinking that goes into a well-designed
-system.
+%In the sections above, I've tried to highlight some of the most
+%important aspects of Mercurial's design, to illustrate that it pays
+%careful attention to reliability and performance.  However, the
+%attention to detail doesn't stop there.  There are a number of other
+%aspects of Mercurial's construction that I personally find
+%interesting.  I'll detail a few of them here, separate from the ``big
+%ticket'' items above, so that if you're interested, you can gain a
+%better idea of the amount of thinking that goes into a well-designed
+%system.
+
+前節でMercurialの設計の最も重要な面について取り上げ，信頼性と性能に細心の
+注意を払っていることを強調した．しかし細部への注意はそれだけに留まらない．
+Mercurialの構造には，個人的に興味深く感じた点が多々ある．巧妙に設計された
+システムの背後にあるアイディアについて読者が興味を持つならば，より深い理
+解が出来るよう，前述した大きな括りとは別にその2,3について取り上げてみよう
+と思う．
 
 %\subsection{Clever compression}
 \subsection{賢い圧縮}
 
-When appropriate, Mercurial will store both snapshots and deltas in
-compressed form.  It does this by always \emph{trying to} compress a
-snapshot or delta, but only storing the compressed version if it's
-smaller than the uncompressed version.
+%When appropriate, Mercurial will store both snapshots and deltas in
+%compressed form.  It does this by always \emph{trying to} compress a
+%snapshot or delta, but only storing the compressed version if it's
+%smaller than the uncompressed version.
+
+適切な場合，Mercurialはスナップショットと差分を圧縮された形式で保存する．
+Mercurialは常にスナップショットや差分の圧縮を\emph{試みる}が，それを保存
+するのは圧縮されたバージョンが元のバージョンよりも小さい時のみである．
+
+%This means that Mercurial does ``the right thing'' when storing a file
+%whose native form is compressed, such as a \texttt{zip} archive or a
+%JPEG image.  When these types of files are compressed a second time,
+%the resulting file is usually bigger than the once-compressed form,
+%and so Mercurial will store the plain \texttt{zip} or JPEG.
 
-This means that Mercurial does ``the right thing'' when storing a file
-whose native form is compressed, such as a \texttt{zip} archive or a
-JPEG image.  When these types of files are compressed a second time,
-the resulting file is usually bigger than the once-compressed form,
-and so Mercurial will store the plain \texttt{zip} or JPEG.
+つまり，Mercurialは\texttt{zip}アーカイブやJPEG画像などのように元々圧縮さ
+れているファイルの保存を``正しいやり方''で行う．これらのファイルでは，差
+分取って圧縮を行っても結果として得られるファイルは通常，元のファイルより
+も大きくなる．そこでMercurialは\texttt{zip}やJPEGをそのまま保存する．
 
-Deltas between revisions of a compressed file are usually larger than
-snapshots of the file, and Mercurial again does ``the right thing'' in
-these cases.  It finds that such a delta exceeds the threshold at
-which it should store a complete snapshot of the file, so it stores
-the snapshot, again saving space compared to a naive delta-only
-approach.
+%Deltas between revisions of a compressed file are usually larger than
+%snapshots of the file, and Mercurial again does ``the right thing'' in
+%these cases.  It finds that such a delta exceeds the threshold at
+%which it should store a complete snapshot of the file, so it stores
+%the snapshot, again saving space compared to a naive delta-only
+%approach.
+
+通常，圧縮されたファイルのリビジョン間の差分はファイルのスナップショット
+より大きい．ここでもMercurialは``正しいやり方''を用いている．このような
+状況で，差分のサイズがファイルの完全なスナップショットとして保存した方が
+有利となる閾値を越えると，差分ではなくスナップショットを保存する．このよ
+うにして単純に差分のみを記録するアプローチよりも記憶領域を節約している．
 
 %\subsubsection{Network recompression}
 \subsubsection{ネットワーク再圧縮}
@@ -594,6 +773,12 @@
 %network connection, Mercurial uncompresses the compressed revision
 %data.
 
+ディスクにリビジョンを保存する際，Mercurialは``deflate''圧縮アルゴリズム
+を用いる．（これは人気の高い\texttt{zip}アーカイブフォーマットと同じアル
+ゴリズムである．）このアルゴリズムは高い圧縮率と高速性をバランスさせてい
+る．しかしリビジョンデータをネットワークで伝送する際にはMercurialは圧縮さ
+れているリビジョンデータを伸長する．
+
 %If the connection is over HTTP, Mercurial recompresses the entire
 %stream of data using a compression algorithm that gives a better
 %compression ratio (the Burrows-Wheeler algorithm from the widely used
@@ -602,10 +787,19 @@
 %substantially reduces the number of bytes to be transferred, yielding
 %better network performance over almost all kinds of network.
 
+HTTPによる接続の場合，Mercurialはデータストリーム全体をより圧縮率の高いア
+ルゴリズム（広く用いられている圧縮パッケージである\texttt{bzip2}で使われ
+ているBurrows-Wheelerアルゴリズム）で再圧縮する．このアルゴリズムと，（リ
+ビジョン毎でなく）ストリーム全体を圧縮することにより，送信されるバイト数
+は大きく低減され，あらゆるネットワークでよい性能をえることができる．
+
 %(If the connection is over \command{ssh}, Mercurial \emph{doesn't}
 %recompress the stream, because \command{ssh} can already do this
 %itself.)
 
+（\command{ssh}による接続の場合，Mercurialはストリームの再圧縮は行わな
+い．\command{ssh}コマンド自体が圧縮を行うためである．）
+
 %\subsection{Read/write ordering and atomicity}
 \subsection{読み書きの順序とアトミック性}
 
@@ -615,17 +809,33 @@
 %revisions in the manifest, and revisions in the manifest point to
 %revisions in filelogs.  This hierarchy is deliberate.
 
+ファイルへの追記は読み手が部分ファイルを読まないことの保証としては十分で
+はない． 図~\ref{fig:concepts:metadata}を思い起こすと，チェンジログ内のリ
+ビジョンはマニフェスト内のリビジョンを指し示しており，マニフェスト内のリ
+ビジョンはファイルログ内のリビジョンを指し示していた．この階層構造は重要
+な意味を持っている．
+
 %A writer starts a transaction by writing filelog and manifest data,
 %and doesn't write any changelog data until those are finished.  A
 %reader starts by reading changelog data, then manifest data, followed
 %by filelog data.
 
+書き手はファイルログとマニフェストを書き込むことでトランザクションを
+開始するが，これらが完了するまでチェンジログデータの書き込みは行わない．
+一方，読み手はチェンジログデータ，マニフェストデータ，ファイルログデータ
+の順に読み出しを行う．
+
 %Since the writer has always finished writing filelog and manifest data
 %before it writes to the changelog, a reader will never read a pointer
 %to a partially written manifest revision from the changelog, and it will
 %never read a pointer to a partially written filelog revision from the
 %manifest.
 
+書き手は常にファイルログとマニフェストデータをチェンジログの前に書き込み
+終了しているため，読み手は部分的に書かれたマニフェストリビジョンへのポイ
+ンタををチェンジログから読み出すことはない．また部分的に書かれたファイル
+ログリビジョンへのポインタをマニフェストから読み出すこともない．
+
 %\subsection{Concurrent access}
 \subsection{同時アクセス}
 
@@ -636,9 +846,15 @@
 %of Mercurial processes safely reading data from a repository safely
 %all at once, no matter whether it's being written to or not.
 
+読み書きの順序とアトミック性の保証により，Mercurialではデータの読み出し時
+にリポジトリの\emph{ロック}が不要になっている．読み出し中に書き込みが発生
+したとしても同様である．このことはスケーラビリティに大きな効果をもたら
+す．多数のMercurialプロセスがあっても，リポジトリへの書き込みの有無に関わ
+らず，リポジトリから一度に安全にデータを読み出すことができる．
+
 %The lockless nature of reading means that if you're sharing a
 %repository on a multi-user system, you don't need to grant other local
-%users permission to \emph{write} to your repository in order for them
+%users permission to \emph{write} to your repositoryin order for them
 %to be able to clone it or pull changes from it; they only need
 %\emph{read} permission.  (This is \emph{not} a common feature among
 %revision control systems, so don't take it for granted!  Most require
@@ -647,6 +863,15 @@
 %makes for all kinds of nasty and annoying security and administrative
 %problems.)
 
+Mercurialでは，ロック無しで読み出しを行うため，マルチユーザシステム上でリ
+ポジトリを共有している場合でもcloneやpullを行おうとする他のローカルユーザ
+にリポジトリへの\emph{書き込み}許可を与える必要はない．彼らには\emph{読み
+出し}許可があればよい．（他のリビジョンコントロールシステムではこうはいか
+ず，大半のシステムでは読み手が安全にリポジトリにアクセスするためにロック
+を取得することを必要とする．これはすなわち読み手が少なくとも1つのディレク
+トリに対して書き込み許可を持っていなければならないことを意味する．このた
+めにセキュリティや管理上の厄介な問題が発生し得る．）
+
 %Mercurial uses locks to ensure that only one process can write to a
 %repository at a time (the locking mechanism is safe even over
 %filesystems that are notoriously hostile to locking, such as NFS).  If
@@ -657,6 +882,15 @@
 %and pile up if a system crashes unnoticed, for example.  (Yes, the
 %timeout is configurable, from zero to infinity.)
 
+Mercurialは一度に1プロセスだけがリポジトリに書き込むことを保証するために
+ロックを使っている．（Mercurialの用いるロックメカニズムはNFSのようにロッ
+クと相性の悪いことで有名なファイルシステム上でも安全である．）リポジトリ
+がロックされると，書き込みプロセスはリポジトリがアンロックされるまでしば
+らく待つ．しかしリポジトリが長時間にわたってロックされ続ける場合は，書き
+込みしようとするプロセスはタイムアウトする．これは，例えば，日常用いる自
+動スクリプトは永遠にスタックするわけではないことを意味する．（もちろんタ
+イムアウトまでの時間はゼロから無限の間で設定かのうである）
+
 %\subsubsection{Safe dirstate access}
 \subsubsection{安全なdirstateアクセス}
 
@@ -668,6 +902,13 @@
 %\filename{dirstate}.  The file named \filename{dirstate} is thus
 %guaranteed to be complete, not partially written.
 
+リビジョンデータの時と同様に，Mercurialはdirstateファイルを読み出す際には
+ロックを行わない．ロックを行うのは書き込みの時のみである．一部のみが書き
+込まれたdirstateファイルを読み込まないようにするため， Mercurialは同じディ
+レクトリ内にユニークな名前でdirstateファイルを書き，この一時ファイルをア
+トミックに\filename{dirstate}にリネームする．これによ
+り，\filename{dirstate}ファイルは常に完全であることが保証される．
+
 %\subsection{Avoiding seeks}
 \subsection{シークの回避}
 
@@ -690,7 +931,6 @@
 
 %Mercurial also uses a ``copy on write'' scheme when cloning a
 %repository on local storage.  Instead of copying every revlog file
-
 %from the old repository into the new repository, it makes a ``hard
 %link'', which is a shorthand way to say ``these two names point to the
 %same file''.  When Mercurial is about to write to one of a revlog's
@@ -700,8 +940,12 @@
 %this repository.
 
 Mercurialはリポジトリをローカルストレージにクローンする際に``コピーオンラ
-イト''手法を使っている．
-
+イト''手法を使っている．元のリポジトリから新しいリポジトリへ全てのrevlog
+ファイルをコピーするのではなく，ハードリンクを作成する．ハードリンクは同
+一のファイルを指し示す別名を作る簡単な方法である． Mercurialはrevlogファ
+イルに書き込みを行う際にファイルを示す名前が2つ以上ある稼働かをチェックす
+る． 2つ以上の名前がある場合，2つ以上のリポジトリがファイルを使用してお
+り，Mercurialはファイルのリポジトリに固有な新しいコピーを作成する．
 
 %A few revision control developers have pointed out that this idea of
 %making a complete private copy of a file is not very efficient in its
@@ -711,6 +955,13 @@
 %performance and increase the complexity of the software, each of which
 %is much more important to the ``feel'' of day-to-day use.
 
+リビジョンコントロールシステムの開発者の幾人かは，ファイルの完全なプライ
+ベートコピーを作るというアイディアは，ストレージの利用量の観点からあまり
+効率的でないと指摘している．これは事実であるが，ストレージは安価であり，
+この方法はOS上で差分を取る場合最高の性能をもたらす．その他の手法は性能を
+損ない，ソフトウェアが複雑になる可能性が高い．これらは日々の使用感よりも
+ずっと重要である．
+
 %\subsection{Other contents of the dirstate}
 \subsection{dirstateの他の内容}
 
@@ -720,10 +971,19 @@
 %in the working directory, it stores the time that it last modified the
 %file itself, and the size of the file at that time.
 
+Mercurialは，ファイルを変更した場合でも，変更の申告を強制しないため，
+dirstateに追加の情報を保存することでファイルを変更したかどうか効果的に判
+別する．ワーキングディレクトリのすべてのファイルについて，最後にファイル
+が変更された時刻と，その際のファイルサイズを記録している．
+
 %When you explicitly \hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} or
 %\hgcmd{copy} files, Mercurial updates the dirstate so that it knows
 %what to do with those files when you commit.
 
+明示的にファイルを\hgcmd{add}, \hgcmd{remove}, \hgcmd{rename} または
+\hgcmd{copy}した場合，Mercurialはdirstateを更新し，コミットの際にそれら
+のファイルをどう取り扱うかを判断する．
+
 %When Mercurial is checking the states of files in the working
 %directory, it first checks a file's modification time.  If that has
 %not changed, the file must not have been modified.  If the file's size
@@ -734,6 +994,15 @@
 %amount of data that Mercurial needs to read, which yields large
 %performance improvements compared to other revision control systems.
 
+Mercurialがワーキングディレクトリのファイルの状態をチェックする際は，まず
+ファイルの更新日時を調べる．これが変更されていない場合はファイルは変更が
+ないということがわかる．ファイルサイズが変わっている場合は，ファイルが変
+更されたことがわかる．更新日時が変わっているが，サイズが同じ場合は
+Mercurialはファイルの内容を直接見て，変更されているかどうかを判断する必要
+がある．これらのごく僅かの情報を保存することによって，Mercurialはデータの
+読み取り量を劇的に削減し，他のリビジョンコントロールシステムと比較して大
+きな性能向上を達成している．
+
 %%% Local Variables:
 %%% mode: yatex
 %%% TeX-master: "00book"
diff -r 93d19b27859c -r 43556decb81f ja/todo.txt
--- a/ja/todo.txt	Tue May 12 17:49:11 2009 +0900
+++ b/ja/todo.txt	Wed Jun 03 15:41:08 2009 +0900
@@ -2,7 +2,7 @@
 00book.tex	100%
 branch.tex	100%
 collab.tex	100%
-concepts.tex     20%
+concepts.tex    100%
 daily.tex	100%
 filenames.tex	100%
 hg_id.tex	noneed