# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1240239034 -32400
# Node ID 5981a0f7540ae9d9d8cc481625984aeb34e3b420
# Parent  2e072e3d86375381ba54ea1c5222949734877aab
finished intro.tex

diff -r 2e072e3d8637 -r 5981a0f7540a ja/intro.tex
--- a/ja/intro.tex	Fri Mar 27 17:39:24 2009 +0900
+++ b/ja/intro.tex	Mon Apr 20 23:50:34 2009 +0900
@@ -98,7 +98,7 @@
 500人からなるプロジェクトでは，リビジョンコントロールツールなしでは殆んど
 立ち行かない．この場合，リビジョンコントロールなしでは失敗することが殆ん
 ど明白なため，リビジョンコントロールを行うコストを払うことは特に問題とは
-ならない．xxx
+ならない．%xxx
 
 %On the other hand, a one-person ``quick hack'' might seem like a poor
 %place to use a revision control tool, because surely the cost of using
@@ -426,8 +426,18 @@
 %be at risk of corruption any time you try to update your client's view
 %of the repository.
 
+オープンソースプロジェクトが好きになり，作業を始めようとするとき，プロジェ
+クトが分散リビジョンコントロールツールを使っていれば，ただちにプロジェク
+トのコアメンバーの仲間となる．彼らがリポジトリを公開していれば，直ちにプ
+ロジェクト履歴をコピーし，変更を行い，内部のメンバーが使っているのと全く
+同じツールを用いて作業結果を記録することができる．対称的にメンバーが中央
+集中型のツールを使っている場合，誰かがあなたに変更を中央のサーバにコミッ
+トする許可を与えない限り，ツールをリードオンリーモードで使用することにな
+る．それまでは変更を記録することはできず，あなたのローカルな変更はリポジ
+トリのクライアントコピーを更新するたびに破壊されるリスクを伴う．
+
 %\subsubsection{The forking non-problem}
-\subsubsection{問題なくフォーク可能}
+\subsubsection{フォークしても問題なし}
 
 %It has been suggested that distributed revision control tools pose
 %some sort of risk to open source projects because they make it easy to
@@ -437,6 +447,12 @@
 %side takes a more or less complete copy of the project's source code,
 %and goes off in its own direction.
 
+オープンソースプロジェクトで分散リビジョンコントロールツールを用いること
+は，プロジェクトの開発をフォークさせるリスクがあると言われている．意見の
+相違や，開発者のグループ間での態度の違いから，彼らがそれ以上共に作業を続
+けることができないと決断することでフォークは起こる．双方の陣営はプロジェ
+クトのソースコードのほぼ完全なコピーからそれぞれの方向に別れていく．
+
 %Sometimes the camps in a fork decide to reconcile their differences.
 %With a centralised revision control system, the \emph{technical}
 %process of reconciliation is painful, and has to be performed largely
@@ -444,6 +460,13 @@
 %``win'', and graft the other team's changes into the tree somehow.
 %This usually loses some or all of one side's revision history.
 
+時にはフォークした陣営が，互いのコードの差異を解消することもある．中央集
+中リビジョンコントロールシステムでは，差異を\emph{技術的に}解決する過程に
+困難を伴い，多くの場合，手動で解消する必要がある．どのリビジョン履歴を残
+すのか決め，ほかのチームによる変更をツリーへなんらかの方法で継ぎ木する必
+要がある．この操作では，通常，一方のリビジョン履歴の一部または全体を失う
+ことになる．
+
 %What distributed tools do with respect to forking is they make forking
 %the \emph{only} way to develop a project.  Every single change that
 %you make is potentially a fork point.  The great strength of this
@@ -451,10 +474,27 @@
 %good at \emph{merging} forks, because forks are absolutely
 %fundamental: they happen all the time.
 
+%分散ツールは，フォークを単にプロジェクトを進めるための一つの方法として扱
+%う．すべての変更は潜在的にフォークポイントになりうる．このアプローチの優
+%位点は，分散リビジョンコントロールツールはフォーク間の\emph{マージ}に極め
+%て優れていることだ．フォークは絶対的に基礎的なことである：これは常に起こ
+%る．
+
+分散ツールは，フォークをプロジェクトを進めるための一つの方法として扱うに
+すぎない．行った変更すべては潜在的にフォークポイントになりうる．分散リビ
+ジョンコントロールツールでは，フォークは日常的に起き，これを取り扱うこと
+は動作の根本である．そのためフォーク間の\emph{マージ}には極めて優れてお
+り，これが分散ツールによるアプローチの大きな利点となっている．
+
 %If every piece of work that everybody does, all the time, is framed in
 %terms of forking and merging, then what the open source world refers
 %to as a ``fork'' becomes \emph{purely} a social issue.  If anything,
 %distributed tools \emph{lower} the likelihood of a fork:
+
+各人が常に行う作業の断片がフォークとマージに位置付けられるならば，オープ
+ンソース界は``フォーク''を\emph{純粋に}社会的な事象として扱うだろう．いず
+れにせよ分散ツールはフォークの蓋然性を\emph{下げる}：
+
 %\begin{itemize}
 %\item They eliminate the social distinction that centralised tools
 %  impose: that between insiders (people with commit access) and
@@ -463,6 +503,13 @@
 %  all that's involved from the perspective of the revision control
 %  software is just another merge.
 %\end{itemize}
+\begin{itemize}
+ \item 中央集中的なツールが課す，コミット権を持った内部の人間と持たない外
+       部の人間の社会的な区別を取り去る
+ \item リビジョンコントロールソフトウェアの観点からすると，同じマージであ
+       るため，社会的なフォークの後に差異を解消するのを容易にする．
+\end{itemize}
+
 
 %Some people resist distributed tools because they want to retain tight
 %control over their projects, and they believe that centralised tools
@@ -474,74 +521,131 @@
 %forgoing the ability to fluidly collaborate with whatever people feel
 %compelled to mirror and fork your history.
 
+プロジェクトを厳格にコントロールしたいために分散ツールに抗う人々もいる．
+彼らは中央集中ツールがこのようなコントロールを与えると考えている．しかし
+そう思っていても，CVSやSubversionリポジトリを公開すれば， （時間はかかっ
+ても）プロジェクトの履歴全体を取得して，コントロールの手の及ばないどこか
+でそれを再現する方法はいくらでもある．結局，履歴をミラーし，フォークする
+ような流動的な協力を排除するようなコントロールは非現実的である．
+
 %\subsection{Advantages for commercial projects}
 \subsection{商用プロジェクトでの利点}
 
-Many commercial projects are undertaken by teams that are scattered
-across the globe.  Contributors who are far from a central server will
-see slower command execution and perhaps less reliability.  Commercial
-revision control systems attempt to ameliorate these problems with
-remote-site replication add-ons that are typically expensive to buy
-and cantankerous to administer.  A distributed system doesn't suffer
-from these problems in the first place.  Better yet, you can easily
-set up multiple authoritative servers, say one per site, so that
-there's no redundant communication between repositories over expensive
-long-haul network links.
+%Many commercial projects are undertaken by teams that are scattered
+%across the globe.  Contributors who are far from a central server will
+%see slower command execution and perhaps less reliability.  Commercial
+%revision control systems attempt to ameliorate these problems with
+%remote-site replication add-ons that are typically expensive to buy
+%and cantankerous to administer.  A distributed system doesn't suffer
+%from these problems in the first place.  Better yet, you can easily
+%set up multiple authoritative servers, say one per site, so that
+%there's no redundant communication between repositories over expensive
+%long-haul network links.
+
+商用プロジェクトの多くは地理的に広がったチームによって開発されている．中
+央サーバは，遠く離れた協力者からはコマンド実行が遅かったり，信頼性が低かっ
+たりするように見える．商用リビジョンコントロールシステムはこの問題の解決
+にリモートサイトの複製を作成するアドオンを提供している．これらの多くは高
+価だったり，管理が複雑だという問題を持っている．分散システムにはそもそも
+これらの問題がない．さらに好ましいことに，複数のサイト毎に正式なサーバを
+簡単に設定することができ，高価な長距離のネットワークリンク上に冗長な通信
+を行うことがない．
 
-Centralised revision control systems tend to have relatively low
-scalability.  It's not unusual for an expensive centralised system to
-fall over under the combined load of just a few dozen concurrent
-users.  Once again, the typical response tends to be an expensive and
-clunky replication facility.  Since the load on a central server---if
-you have one at all---is many times lower with a distributed
-tool (because all of the data is replicated everywhere), a single
-cheap server can handle the needs of a much larger team, and
-replication to balance load becomes a simple matter of scripting.
+%Centralised revision control systems tend to have relatively low
+%scalability.  It's not unusual for an expensive centralised system to
+%fall over under the combined load of just a few dozen concurrent
+%users.  Once again, the typical response tends to be an expensive and
+%clunky replication facility.  Since the load on a central server---if
+%you have one at all---is many times lower with a distributed
+%tool (because all of the data is replicated everywhere), a single
+%cheap server can handle the needs of a much larger team, and
+%replication to balance load becomes a simple matter of scripting.
 
-If you have an employee in the field, troubleshooting a problem at a
-customer's site, they'll benefit from distributed revision control.
-The tool will let them generate custom builds, try different fixes in
-isolation from each other, and search efficiently through history for
-the sources of bugs and regressions in the customer's environment, all
-without needing to connect to your company's network.
+中央集中型のリビジョンコントロールシステムのスケーラビリティは相対的に小
+さく，数十人のユーザの同時アクセスによる負荷で中央の高価なシステムが停止
+することも珍しくない．しかし，これに高価で複雑な複製機能を追加することが
+よく行わてしまう．ただ一つの中央サーバのみを持つ場合でも，分散ツールを用
+いることで（データはすべてあらゆるところに複製されるため）中央サーバの負
+荷は数分の一に抑えられる．このため単一の安価なサーバで大きなチームの需要
+を満たすことができ，負荷分散のためのデータの複製もスクリプトだけで実現で
+きる．
+
+%If you have an employee in the field, troubleshooting a problem at a
+%customer's site, they'll benefit from distributed revision control.
+%The tool will let them generate custom builds, try different fixes in
+%isolation from each other, and search efficiently through history for
+%the sources of bugs and regressions in the customer's environment, all
+%without needing to connect to your company's network.
+
+顧客の側でこの領域の問題解決を行う従業員がいれば，分散リビジョンコントロー
+ルの利益を得ることができる．ツールを使うことで，カスタムビルド，互いに独
+立した修正のテスト，プロジェクトの履歴からバグやリグレッションの原因の探
+索などを顧客の環境でネットワークに接続する必要なく実現できる．
 
 %\section{Why choose Mercurial?}
 \section{Mercurialを選ぶ理由}
 
-Mercurial has a unique set of properties that make it a particularly
-good choice as a revision control system.
+%Mercurial has a unique set of properties that make it a particularly
+%good choice as a revision control system.
+Mercurialは，リビジョンコントロールシステムとして選択するのにふさわしい
+ユニークな性質を持っている．
 \begin{itemize}
-\item It is easy to learn and use.
-\item It is lightweight.
-\item It scales excellently.
-\item It is easy to customise.
+%\item It is easy to learn and use.
+%\item It is lightweight.
+%\item It scales excellently.
+%\item It is easy to customise.
+\item 学習と利用が簡単
+\item 軽量である
+\item 極めて良好にスケールする
+\item カスタマイズが容易である
 \end{itemize}
 
-If you are at all familiar with revision control systems, you should
-be able to get up and running with Mercurial in less than five
-minutes.  Even if not, it will take no more than a few minutes
-longer.  Mercurial's command and feature sets are generally uniform
-and consistent, so you can keep track of a few general rules instead
-of a host of exceptions.
+%If you are at all familiar with revision control systems, you should
+%be able to get up and running with Mercurial in less than five
+%minutes.  Even if not, it will take no more than a few minutes
+%longer.  Mercurial's command and feature sets are generally uniform
+%and consistent, so you can keep track of a few general rules instead
+%of a host of exceptions.
+
+読者がリビジョンコントロールに慣れているのであれば， Mercurialを5分以内に
+使い始めることができるだろう． 仮に5分が無理でも，あと数分もあれば十分に
+違いない． Mercurialのコマンドと機能セットは全体に均一で一貫性があるの
+で，多数の例外を覚えるのではなく，共通するルールさえ覚えておけばよい．
+
+%On a small project, you can start working with Mercurial in moments.
+%Creating new changes and branches; transferring changes around
+%(whether locally or over a network); and history and status operations
+%are all fast.  Mercurial attempts to stay nimble and largely out of
+%your way by combining low cognitive overhead with blazingly fast
+%operations.
 
-On a small project, you can start working with Mercurial in moments.
-Creating new changes and branches; transferring changes around
-(whether locally or over a network); and history and status operations
-are all fast.  Mercurial attempts to stay nimble and largely out of
-your way by combining low cognitive overhead with blazingly fast
-operations.
+小さなプロジェクトでは，すぐにMercurialを使い始めることができる．新しい変
+更とブランチを作り，（ローカルやネットワーク越しに）変更を転送し，履歴と
+状態に関する動作はすべて高速である． Mercurialの個々の動作は極めて高速で
+あり，全体としても素早く，オーバヘッドがほとんど知覚できないような動作を
+するようになっている．
+
+%The usefulness of Mercurial is not limited to small projects: it is
+%used by projects with hundreds to thousands of contributors, each
+%containing tens of thousands of files and hundreds of megabytes of
+%source code.
 
-The usefulness of Mercurial is not limited to small projects: it is
-used by projects with hundreds to thousands of contributors, each
-containing tens of thousands of files and hundreds of megabytes of
-source code.
+Mercurialの有用性は，小さなプロジェクトに限らない．Mercurialは数百人から
+数千人の貢献者を擁し，数万のファイルからなる数百メガバイトにも及ぶソース
+コードからなるプロジェクトでも有効である．
 
-If the core functionality of Mercurial is not enough for you, it's
-easy to build on.  Mercurial is well suited to scripting tasks, and
-its clean internals and implementation in Python make it easy to add
-features in the form of extensions.  There are a number of popular and
-useful extensions already available, ranging from helping to identify
-bugs to improving performance.
+%If the core functionality of Mercurial is not enough for you, it's
+%easy to build on.  Mercurial is well suited to scripting tasks, and
+%its clean internals and implementation in Python make it easy to add
+%features in the form of extensions.  There are a number of popular and
+%useful extensions already available, ranging from helping to identify
+%bugs to improving performance.
+
+Mercurialの核になる機能が十分でなかった場合，拡張することはたやすい．
+Mercurialはスクリプトとよく馴染む．また整った内部構造とPythonによる実装の
+ため，拡張の形で新しい機能を追加するのが容易である．バグの識別を助けるも
+のから，性能を改善するものまで，人気の高い有用な拡張がすでに数多く存在し
+ている．
 
 %\section{Mercurial compared with other tools}
 \section{Mercurialと他のツールの比較}
@@ -555,71 +659,123 @@
 アスがかかっていることを理解して欲しい．筆者は下記のリビジョンコントロー
 ルツールのすべてを使用したことがあり，その使用期間は多くの場合数年に及ぶ．
 
-
 \subsection{Subversion}
 
-Subversion is a popular revision control tool, developed to replace
-CVS.  It has a centralised client/server architecture.
+%Subversion is a popular revision control tool, developed to replace
+%CVS.  It has a centralised client/server architecture.
+
+Subversionは，CVSを置き換えるべく開発された，人気の高いリビジョンコントロー
+ルツールである．これも中央集中型のクライアントサーバアーキテクチャを持つ．
+
+%Subversion and Mercurial have similarly named commands for performing
+%the same operations, so if you're familiar with one, it is easy to
+%learn to use the other.  Both tools are portable to all popular
+%operating systems.
 
-Subversion and Mercurial have similarly named commands for performing
-the same operations, so if you're familiar with one, it is easy to
-learn to use the other.  Both tools are portable to all popular
-operating systems.
+SubversionとMercurialでは，同じ動作のためのコマンドに同様の名前が付けられ
+ているため，どちらかに慣れていればもう一方を学ぶのはたやすい．どちらのツー
+ルもすべての人気の高いオペレーティングシステムに移植されている．
+
+%Subversion lacks a history-aware merge capability, forcing its users
+%to manually track exactly which revisions have been merged between
+%branches.  If users fail to do this, or make mistakes, they face the
+%prospect of manually resolving merges with unnecessary conflicts.
+%Subversion also fails to merge changes when files or directories are
+%renamed.  Subversion's poor merge support is its single biggest
+%weakness.
 
-Subversion lacks a history-aware merge capability, forcing its users
-to manually track exactly which revisions have been merged between
-branches.  If users fail to do this, or make mistakes, they face the
-prospect of manually resolving merges with unnecessary conflicts.
-Subversion also fails to merge changes when files or directories are
-renamed.  Subversion's poor merge support is its single biggest
-weakness.
+Subversionは履歴を考慮したマージの機能を欠いており，正確にどのリビジョン
+がブランチ間でマージされたのかユーザ自身がトラックする必要がある。ユーザ
+が追い切れなかった場合や間違いを犯した場合，必要のないコンフリクトを手動
+で解決することになる．Subversionはファイルやディレクトリがリネームされて
+いた場合もマージに失敗する．マージサポートの弱さはSubversionの最大の弱点
+の一つである．
 
-Mercurial has a substantial performance advantage over Subversion on
-every revision control operation I have benchmarked.  I have measured
-its advantage as ranging from a factor of two to a factor of six when
-compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
-the fastest access method available).  In more realistic deployments
-involving a network-based store, Subversion will be at a substantially
-larger disadvantage.  Because many Subversion commands must talk to
-the server and Subversion does not have useful replication facilities,
-server capacity and network bandwidth become bottlenecks for modestly
-large projects.
+%Mercurial has a substantial performance advantage over Subversion on
+%every revision control operation I have benchmarked.  I have measured
+%its advantage as ranging from a factor of two to a factor of six when
+%compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
+%the fastest access method available.  In more realistic deployments
+%involving a network-based store, Subversion will be at a substantially
+%larger disadvantage.  Because many Subversion commands must talk to
+%the server and Subversion does not have useful replication facilities,
+%server capacity and network bandwidth become bottlenecks for modestly
+%large projects.
+
+Mercurialは筆者がベンチマークを行った全てのリビジョンコントロール操作にお
+いてSubversionよりも明確な性能上の優位性を持っている．筆者は2から6までの
+範囲で優位性をSubversion~1.4.3で利用可能な中で最も高速な\emph{ra\_ローカ
+ル}ファイル保存と比較した．より現実的な利用ではネットワークを利用したファ
+イルサービスを用いることになり，Subversionでは明確に大きな不利がある．多
+くのSubversionコマンドはサーバと通信する必要があり，Subversionは実用的な
+複製機構を持たないため，一定以上の規模のプロジェクトでは，サーバキャパシ
+ティとネットワークのバンド幅がボトルネックとなるからである．
+
+%Additionally, Subversion incurs substantial storage overhead to avoid
+%network transactions for a few common operations, such as finding
+%modified files (\texttt{status}) and displaying modifications against
+%the current revision (\texttt{diff}).  As a result, a Subversion
+%working copy is often the same size as, or larger than, a Mercurial
+%repository and working directory, even though the Mercurial repository
+%contains a complete history of the project.
 
-Additionally, Subversion incurs substantial storage overhead to avoid
-network transactions for a few common operations, such as finding
-modified files (\texttt{status}) and displaying modifications against
-the current revision (\texttt{diff}).  As a result, a Subversion
-working copy is often the same size as, or larger than, a Mercurial
-repository and working directory, even though the Mercurial repository
-contains a complete history of the project.
+さらに，Subversionは更新されたファイルの探索(\texttt{status})と，現在のリ
+ビジョンに対する差分のを表示(\texttt{diff})などのいくつかの操作でネットワー
+クトランザクションを避けるために明確なストレージオーバヘッドをもたらす．
+結果として，Subversionのワーキングコピーは，プロジェクトの完全な履歴を含
+むMercurialのリポジトリ及びワーキングディレクトリと同じかより大きなサイズ
+となってしまう．
+
+%Subversion is widely supported by third party tools.  Mercurial
+%currently lags considerably in this area.  This gap is closing,
+%however, and indeed some of Mercurial's GUI tools now outshine their
+%Subversion equivalents.  Like Mercurial, Subversion has an excellent
+%user manual.
 
-Subversion is widely supported by third party tools.  Mercurial
-currently lags considerably in this area.  This gap is closing,
-however, and indeed some of Mercurial's GUI tools now outshine their
-Subversion equivalents.  Like Mercurial, Subversion has an excellent
-user manual.
+Subversionには多くのサードパーティツールがある．Mercurialはこの点でかなり
+遅れている．ギャップは縮まりつつあるが，MercurialのGUIツールのいくつか
+は，対応するSubversion用のものよりも秀でている．SubversionにはMercurialと
+同様に優れたユーザマニュアルがある．
+
+%Because Subversion doesn't store revision history on the client, it is
+%well suited to managing projects that deal with lots of large, opaque
+%binary files.  If you check in fifty revisions to an incompressible
+%10MB file, Subversion's client-side space usage stays constant. The
+%space used by any distributed SCM will grow rapidly in proportion to
+%the number of revisions, because the differences between each revision
+%are large.
 
-Because Subversion doesn't store revision history on the client, it is
-well suited to managing projects that deal with lots of large, opaque
-binary files.  If you check in fifty revisions to an incompressible
-10MB file, Subversion's client-side space usage stays constant The
-space used by any distributed SCM will grow rapidly in proportion to
-the number of revisions, because the differences between each revision
-are large.
+Subversionはリビジョンの履歴をクライアント内に持たないため，サイズが大き
+く内容の明らかでない多数のバイナリファイルを取り扱うのには向いている．
+圧縮の効かない10MBのファイルに対して50リビジョンをチェックインする場
+合，Subversionのクライアント側のストレージの使用量は一定である．
+分散SCMでは，ストレージ使用量は各々のリビジョン間での差分が大きいため，リ
+ビジョン数に比例してすぐに増えてしまう．
+
+%In addition, it's often difficult or, more usually, impossible to
+%merge different versions of a binary file.  Subversion's ability to
+%let a user lock a file, so that they temporarily have the exclusive
+%right to commit changes to it, can be a significant advantage to a
+%project where binary files are widely used.
 
-In addition, it's often difficult or, more usually, impossible to
-merge different versions of a binary file.  Subversion's ability to
-let a user lock a file, so that they temporarily have the exclusive
-right to commit changes to it, can be a significant advantage to a
-project where binary files are widely used.
+加えて，異なるバージョンのバイナリファイルをマージするのは不可能であった
+り，困難であったりする． Subversionではファイルロック機能によってユーザが
+一時的にファイルへの変更をコミットする排他的な権利を得ることができる．こ
+れはバイナリファイルを広汎に使うプロジェクトでは大きな利点になり得る．
 
-Mercurial can import revision history from a Subversion repository.
-It can also export revision history to a Subversion repository.  This
-makes it easy to ``test the waters'' and use Mercurial and Subversion
-in parallel before deciding to switch.  History conversion is
-incremental, so you can perform an initial conversion, then small
-additional conversions afterwards to bring in new changes.
+%Mercurial can import revision history from a Subversion repository.
+%It can also export revision history to a Subversion repository.  This
+%makes it easy to ``test the waters'' and use Mercurial and Subversion
+%in parallel before deciding to switch.  History conversion is
+%incremental, so you can perform an initial conversion, then small
+%additional conversions afterwards to bring in new changes.
 
+MercurialはSubversionリポジトリからリビジョン履歴をインポートすることがで
+きる．また，リビジョン履歴をSubversionリポジトリにエクスポートすることも
+可能だ．このため，移行を決める前にMercurialを試したり，Mercurialを
+Subversionと並行して利用することが容易である．
+履歴の変換は漸進的に行えるため，最初に変換を行った後，新たな変更を取り込
+むために追加の変換を行うことができる．
 
 \subsection{Git}
 
@@ -682,44 +838,73 @@
 
 MercurialはGitリポジトリからリビジョン履歴をインポートすることができる．
 
-
 \subsection{CVS}
 
-CVS is probably the most widely used revision control tool in the
-world.  Due to its age and internal untidiness, it has been only
-lightly maintained for many years.
+%CVS is probably the most widely used revision control tool in the
+%world.  Due to its age and internal untidiness, it has been only
+%lightly maintained for many years.
+
+CVSはおそらく世界中で最も広範に使用されているリビジョンコントロールツー
+ルであろう．その古さと内部の乱雑さのため，長らく軽いメンテナンスのみが行
+われてきた．
 
-It has a centralised client/server architecture.  It does not group
-related file changes into atomic commits, making it easy for people to
-``break the build'': one person can successfully commit part of a
-change and then be blocked by the need for a merge, causing other
-people to see only a portion of the work they intended to do.  This
-also affects how you work with project history.  If you want to see
-all of the modifications someone made as part of a task, you will need
-to manually inspect the descriptions and timestamps of the changes
-made to each file involved (if you even know what those files were).
+%It has a centralised client/server architecture.  It does not group
+%related file changes into atomic commits, making it easy for people to
+%``break the build'': one person can successfully commit part of a
+%change and then be blocked by the need for a merge, causing other
+%people to see only a portion of the work they intended to do.  This
+%also affects how you work with project history.  If you want to see
+%all of the modifications someone made as part of a task, you will need
+%to manually inspect the descriptions and timestamps of the changes
+%made to each file involved (if you even know what those files were).
+
+CVSは集中型のクライアントサーバアーキテクチャを持つ．CVSは，関連したファ
+イル変更をグループ化し，アトミックにコミットすることができない．このため
+ユーザがコミットによってビルドを破壊することが起こる．誰かが変更の一部を
+成功裏にコミットしたものの，残りの部分はマージが必要なためブロックされて
+いる場合，他のユーザは必要な変更の一部しか見ることができない．同じことは
+プロジェクトの履歴に対しても起こる．誰かの作業に関係する変更すべてを参照
+したい場合，（どのファイルが何なのか知っていれば）関連する各ファイルにつ
+いて，変更の説明とタイムスタンプを自力で調べて変更を特定する必要がある．
 
-CVS has a muddled notion of tags and branches that I will not attempt
-to even describe.  It does not support renaming of files or
-directories well, making it easy to corrupt a repository.  It has
-almost no internal consistency checking capabilities, so it is usually
-not even possible to tell whether or how a repository is corrupt.  I
-would not recommend CVS for any project, existing or new.
+%CVS has a muddled notion of tags and branches that I will not attempt
+%to even describe.  It does not support renaming of files or
+%directories well, making it easy to corrupt a repository.  It has
+%almost no internal consistency checking capabilities, so it is usually
+%not even possible to tell whether or how a repository is corrupt.  I
+%would not recommend CVS for any project, existing or new.
+
+CVSのタグとブランチは語る気さえ起きないような混乱した形式を持っている．き
+ちんとしたファイルやディレクトリのリネームをサポートしないため，リポジト
+リが簡単に壊れてしまう． cvsは内部で一貫性をチェックする機能がなく，リポ
+ジトリの破損を知らせることもできない．筆者は既存または新規を問わず，どの
+ようなプロジェクトであってもCVSの使用は薦めない．
 
-Mercurial can import CVS revision history.  However, there are a few
-caveats that apply; these are true of every other revision control
-tool's CVS importer, too.  Due to CVS's lack of atomic changes and
-unversioned filesystem hierarchy, it is not possible to reconstruct
-CVS history completely accurately; some guesswork is involved, and
-renames will usually not show up.  Because a lot of advanced CVS
-administration has to be done by hand and is hence error-prone, it's
-common for CVS importers to run into multiple problems with corrupted
-repositories (completely bogus revision timestamps and files that have
-remained locked for over a decade are just two of the less interesting
-problems I can recall from personal experience).
+%Mercurial can import CVS revision history.  However, there are a few
+%caveats that apply; these are true of every other revision control
+%tool's CVS importer, too.  Due to CVS's lack of atomic changes and
+%unversioned filesystem hierarchy, it is not possible to reconstruct
+%CVS history completely accurately; some guesswork is involved, and
+%renames will usually not show up.  Because a lot of advanced CVS
+%administration has to be done by hand and is hence error-prone, it's
+%common for CVS importers to run into multiple problems with corrupted
+%repositories (completely bogus revision timestamps and files that have
+%remained locked for over a decade are just two of the less interesting
+%problems I can recall from personal experience).
 
-Mercurial can import revision history from a CVS repository.
+MercurialはCVSのリビジョン履歴をインポートすることができる．しかし他のリ
+ビジョンコントロールツールのCVSインポーター同様いくつかの制限もある．
+CVSにはアトミックチェンジがなく，ファイルシステム階層をバージョン管理す
+る能力もないため，CVSの履歴を完全かつ正確に再現することはできない．再現
+にはいくつかの推測が入り，リネームは通常再現されない．
+CVSでは高度な管理の多くが手動で行われるため，間違いが起こりやすく，破損し
+たリポジトリでCVSインポーターが同時に複数の問題に見舞われることがよくあ
+る．（筆者の不愉快な体験では，10年以上にわたってロックされたままの完全に
+無意味なリビジョンタイムスタンプやファイルを見たことがある．）
 
+%Mercurial can import revision history from a CVS repository.
+
+MercurialはCVSリポジトリからリビジョン履歴をインポートすることができる．
 
 %\subsection{Commercial tools}
 \subsection{商用ツール}
diff -r 2e072e3d8637 -r 5981a0f7540a ja/todo.txt
--- a/ja/todo.txt	Fri Mar 27 17:39:24 2009 +0900
+++ b/ja/todo.txt	Mon Apr 20 23:50:34 2009 +0900
@@ -8,7 +8,7 @@
 hg_id.tex	noneed
 hgext.tex	100%
 hook.tex	50%
-intro.tex	40%
+intro.tex	100%
 license.tex
 mq-collab.tex   100%
 mq-ref.tex	100%