# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1235228215 -32400
# Node ID 63060ad65ab849b9a147031a4ef8fe41e12c6643
# Parent  b7cdede6065fff64c76a7c47fd7e0637c8e74e49
started intro.tex

diff -r b7cdede6065f -r 63060ad65ab8 ja/intro.tex
--- a/ja/intro.tex	Sat Feb 21 22:07:30 2009 +0900
+++ b/ja/intro.tex	Sat Feb 21 23:56:55 2009 +0900
@@ -1,166 +1,295 @@
-\chapter{Introduction}
+%\chapter{Introduction}
+\chapter{導入}
 \label{chap:intro}
 
-\section{About revision control}
+%\section{About revision control}
+\section{リビジョンコントロール}
 
-Revision control is the process of managing multiple versions of a
-piece of information.  In its simplest form, this is something that
-many people do by hand: every time you modify a file, save it under a
-new name that contains a number, each one higher than the number of
-the preceding version.
+%Revision control is the process of managing multiple versions of a
+%piece of information.  In its simplest form, this is something that
+%many people do by hand: every time you modify a file, save it under a
+%new name that contains a number, each one higher than the number of
+%the preceding version.
+
+リビジョンコントロールとは，複数のバージョンの情報をを管理するプロセスで
+ある．最も単純な方法は，ファイルを変更したら，それまでのバージョンよりも
+大きな数字を含む新たな名前でセーブを行うなどの方法で全て手で行うことであ
+る．
 
-Manually managing multiple versions of even a single file is an
-error-prone task, though, so software tools to help automate this
-process have long been available.  The earliest automated revision
-control tools were intended to help a single user to manage revisions
-of a single file.  Over the past few decades, the scope of revision
-control tools has expanded greatly; they now manage multiple files,
-and help multiple people to work together.  The best modern revision
-control tools have no problem coping with thousands of people working
-together on projects that consist of hundreds of thousands of files.
+%Manually managing multiple versions of even a single file is an
+%error-prone task, though, so software tools to help automate this
+%process have long been available.  The earliest automated revision
+%control tools were intended to help a single user to manage revisions
+%of a single file.  Over the past few decades, the scope of revision
+%control tools has expanded greatly; they now manage multiple files,
+%and help multiple people to work together.  The best modern revision
+%control tools have no problem coping with thousands of people working
+%together on projects that consist of hundreds of thousands of files.
 
-\subsection{Why use revision control?}
+たった一つのファイルに対しても，複数のバージョンを手で管理することは間違
+いを起こし易い作業で，このプロセスを自動化するソフトウェアツールがかなり
+の昔から提供されてきた．最初の自動化されたリビジョンコントロールツール
+は，一人のユーザを対象として，1つのファイルのリビジョンを管理するために作
+られた．数十年が経ち，リビジョンコントロールの取り扱うスコープは大いに拡
+大した．今では複数人による複数ファイルの編集をも管理することができる．現
+代の最高のリビジョン管理ツールは数千人による，数十万個のファイルを擁する
+プロジェクトにも対応する．
 
-There are a number of reasons why you or your team might want to use
-an automated revision control tool for a project.
+%\subsection{Why use revision control?}
+\subsection{なぜリビジョンコントロールを使うのか?}
+
+%There are a number of reasons why you or your team might want to use
+%an automated revision control tool for a project.
+プロジェクトのために自動化されたリビジョンコントロールツールを使おうと考
+える理由は数多くある．
 \begin{itemize}
-\item It will track the history and evolution of your project, so you
-  don't have to.  For every change, you'll have a log of \emph{who}
-  made it; \emph{why} they made it; \emph{when} they made it; and
-  \emph{what} the change was.
-\item When you're working with other people, revision control software
-  makes it easier for you to collaborate.  For example, when people
-  more or less simultaneously make potentially incompatible changes,
-  the software will help you to identify and resolve those conflicts.
-\item It can help you to recover from mistakes.  If you make a change
-  that later turns out to be in error, you can revert to an earlier
-  version of one or more files.  In fact, a \emph{really} good
-  revision control tool will even help you to efficiently figure out
-  exactly when a problem was introduced (see
-  section~\ref{sec:undo:bisect} for details).
-\item It will help you to work simultaneously on, and manage the drift
-  between, multiple versions of your project.
+%\item It will track the history and evolution of your project, so you
+%  don't have to.  For every change, you'll have a log of \emph{who}
+%  made it; \emph{why} they made it; \emph{when} they made it; and
+%  \emph{what} the change was.
+ \item リビジョン管理ツールは，プロジェクトの履歴と進化を記録するため，自
+       分自身で記録する必要がない．全ての変更に対して\emph{誰が}\emph{何
+       のために}\emph{いつ}\emph{何を}変更したのかが記録される．
+%\item When you're working with other people, revision control software
+%  makes it easier for you to collaborate.  For example, when people
+%  more or less simultaneously make potentially incompatible changes,
+%  the software will help you to identify and resolve those conflicts.
+ \item 他の人と作業している時，リビジョンコントロールソフトウェアは共同
+       作業を助ける．例えば，人々が同時に互換性のない変更を行った場合，
+       ソフトウェアはコンフリクトを特定し，可決することを助ける．
+%\item It can help you to recover from mistakes.  If you make a change
+%  that later turns out to be in error, you can revert to an earlier
+%  version of one or more files.  In fact, a \emph{really} good
+%  revision control tool will even help you to efficiently figure out
+%  exactly when a problem was introduced (see
+%  section~\ref{sec:undo:bisect} for details).
+ \item リビジョン管理ツールは犯したミスからの回復を助ける．加えた変更が後
+で間違いであったと分かった時，1つまたは複数のファイルへの変更を破棄するこ
+とができる．実際のところ，\emph{真に}優れたリビジョンコントロールツールは
+紛れ込んだ問題を特定するのを支援する機能を持つ．（詳細について
+は~\ref{sec:undo:bisect}節を参照．）
+%\item It will help you to work simultaneously on, and manage the drift
+%  between, multiple versions of your project.
+ \item リビジョン管理ツールは，プロジェクトの複数のバージョンでの同時作
+       業や，リビジョン間の移行を支援する．
 \end{itemize}
-Most of these reasons are equally valid---at least in theory---whether
-you're working on a project by yourself, or with a hundred other
-people.
+%Most of these reasons are equally valid---at least in theory---whether
+%you're working on a project by yourself, or with a hundred other
+%people.
+これらの理由の多くは自分自身のプロジェクトで作業していても，100人の共同作
+業者と作業していても少なくとも理論的には等しく有意である．
 
-A key question about the practicality of revision control at these two
-different scales (``lone hacker'' and ``huge team'') is how its
-\emph{benefits} compare to its \emph{costs}.  A revision control tool
-that's difficult to understand or use is going to impose a high cost.
+%A key question about the practicality of revision control at these two
+%different scales (``lone hacker'' and ``huge team'') is how its
+%\emph{benefits} compare to its \emph{costs}.  A revision control tool
+%that's difficult to understand or use is going to impose a high cost.
+
+リビジョンコントロールの実用性に関する鍵になる質問は，これらの2つの異なっ
+たスケール（``一人のハッカー''レベルから``大規模チーム''レベルまで）にお
+いて，コストに対してどれだけ利益があるのかということである．理解や使用が
+困難なリビジョンコントロールツールは高いコストを押しつける．
 
-A five-hundred-person project is likely to collapse under its own
-weight almost immediately without a revision control tool and process.
-In this case, the cost of using revision control might hardly seem
-worth considering, since \emph{without} it, failure is almost
-guaranteed.
+%A five-hundred-person project is likely to collapse under its own
+%weight almost immediately without a revision control tool and process.
+%In this case, the cost of using revision control might hardly seem
+%worth considering, since \emph{without} it, failure is almost
+%guaranteed.
 
-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
-one must be close to the overall cost of the project.  Right?
+500人からなるプロジェクトでは，リビジョンコントロールツールなしでは殆んど
+立ち行かない．この場合，リビジョンコントロールなしでは失敗することが殆ん
+ど明白なため，リビジョンコントロールを行うコストを払うことは特に問題とは
+ならない．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
+%one must be close to the overall cost of the project.  Right?
+
+一方，1人の開発者による``クイックハック''はリビジョンコントロールツール
+を使うにはあまりふさわしくない．なぜなら，ツールを使うコストがほぼプロジェ
+クトのコストそのものであるからだ．これは正しいだろうか？
 
-Mercurial uniquely supports \emph{both} of these scales of
-development.  You can learn the basics in just a few minutes, and due
-to its low overhead, you can apply revision control to the smallest of
-projects with ease.  Its simplicity means you won't have a lot of
-abstruse concepts or command sequences competing for mental space with
-whatever you're \emph{really} trying to do.  At the same time,
-Mercurial's high performance and peer-to-peer nature let you scale
-painlessly to handle large projects.
+%Mercurial uniquely supports \emph{both} of these scales of
+%development.  You can learn the basics in just a few minutes, and due
+%to its low overhead, you can apply revision control to the smallest of
+%projects with ease.  Its simplicity means you won't have a lot of
+%abstruse concepts or command sequences competing for mental space with
+%whatever you're \emph{really} trying to do.  At the same time,
+%Mercurial's high performance and peer-to-peer nature let you scale
+%painlessly to handle large projects.
+
+Mercurialはこれらの開発スケールの両方をサポートしている．基礎的な使用法は
+数分で学ぶことができ，リビジョンコントロールを最小規模のプロジェクトに簡
+単に取り入れることができる．単純であるため，難解なコンセプトやコマンドシー
+ケンスに意識の多くを占められ，本当にやりたいことが疎かになることもない．
+また同時にMercurialの性能の高さや，ピアツーピアの性質のために，大規模プロ
+ジェクトにも苦労する事なくスケールすることができる．
 
-No revision control tool can rescue a poorly run project, but a good
-choice of tools can make a huge difference to the fluidity with which
-you can work on a project.
+%No revision control tool can rescue a poorly run project, but a good
+%choice of tools can make a huge difference to the fluidity with which
+%you can work on a project.
+
+お粗末なプロジェクトを救済するようなリビジョンコントロールは存在しない
+が，良いツールの選択は，作業するプロジェクトの堅実さに大きな差をもたらす．
 
-\subsection{The many names of revision control}
+%\subsection{The many names of revision control}
+\subsection{様々なリビジョンコントロール}
 
-Revision control is a diverse field, so much so that it doesn't
-actually have a single name or acronym.  Here are a few of the more
-common names and acronyms you'll encounter:
+%Revision control is a diverse field, so much so that it doesn't
+%actually have a single name or acronym.  Here are a few of the more
+%common names and acronyms you'll encounter:
+リビジョンコントロールは大きな幅をもつ分野であり，そのため多くの呼び名と
+その短縮形が知られている：
 \begin{itemize}
-\item Revision control (RCS)
-\item Software configuration management (SCM), or configuration management
-\item Source code management
-\item Source code control, or source control
-\item Version control (VCS)
+\item リビジョンコントロール (Revision control (RCS))
+\item ソフトウェア設定マネジメントまたは設定マネジメント (Software configuration management (SCM), or configuration management)
+\item ソースコードマネジメント (Source code management)
+\item ソースコードコントロールまたはソースコントロール (Source code control, or source control)
+\item バージョンコントロール (Version control (VCS))
 \end{itemize}
-Some people claim that these terms actually have different meanings,
-but in practice they overlap so much that there's no agreed or even
-useful way to tease them apart.
+%Some people claim that these terms actually have different meanings,
+%but in practice they overlap so much that there's no agreed or even
+%useful way to tease them apart.
+これらの用語は各々違う意味を持つのだと主張する人々もいる．しかし実質的に
+はこれらは互いに大きく重なっており，わざわざ区別することは一般的でなく，
+また有用でもない．
+
+%\section{A short history of revision control}
+\section{リビジョンコントロールの歴史}
 
-\section{A short history of revision control}
+%The best known of the old-time revision control tools is SCCS (Source
+%Code Control System), which Marc Rochkind wrote at Bell Labs, in the
+%early 1970s.  SCCS operated on individual files, and required every
+%person working on a project to have access to a shared workspace on a
+%single system.  Only one person could modify a file at any time;
+%arbitration for access to files was via locks.  It was common for
+%people to lock files, and later forget to unlock them, preventing
+%anyone else from modifying those files without the help of an
+%administrator.
+
+最も知られている古いリビジョンコントロールツールは，Marc Rochkindが1970年
+代初頭にBell研究所で書いたSCCS (Source Code Control System)である． SCCS
+は個々のファイルに対して動作し，プロジェクトの共同作業者には同一マシン上
+の共有ワークスペースへのアクセスが必要であった．ファイルへのアクセスの調
+停はロックによって行われ，あるファイルを変更できるのは常に一人のユーザだ
+けであった．ファイルをロックした後，ロックの解除を忘れることは日常的にあ
+り，こうなると管理者の助けなしに他の開発者がファイルを変更することはでき
+なかった．
 
-The best known of the old-time revision control tools is SCCS (Source
-Code Control System), which Marc Rochkind wrote at Bell Labs, in the
-early 1970s.  SCCS operated on individual files, and required every
-person working on a project to have access to a shared workspace on a
-single system.  Only one person could modify a file at any time;
-arbitration for access to files was via locks.  It was common for
-people to lock files, and later forget to unlock them, preventing
-anyone else from modifying those files without the help of an
-administrator.  
+%Walter Tichy developed a free alternative to SCCS in the early 1980s;
+%he called his program RCS (Revison Control System).  Like SCCS, RCS
+%required developers to work in a single shared workspace, and to lock
+%files to prevent multiple people from modifying them simultaneously.
+
+Walter Tichyは，1980年代初頭にSCCSの代替となるフリーのバージョンコントロー
+ルツールを開発した．彼は自らのシステムをRCS (Revison Control System)と呼
+んだ．SCCS同様，RCSは開発者たちに単一の共有ワークスペースと，ファイルを同
+時に複数人が変更することのないようにロックを要求した．
 
-Walter Tichy developed a free alternative to SCCS in the early 1980s;
-he called his program RCS (Revison Control System).  Like SCCS, RCS
-required developers to work in a single shared workspace, and to lock
-files to prevent multiple people from modifying them simultaneously.
+%Later in the 1980s, Dick Grune used RCS as a building block for a set
+%of shell scripts he initially called cmt, but then renamed to CVS
+%(Concurrent Versions System).  The big innovation of CVS was that it
+%let developers work simultaneously and somewhat independently in their
+%own personal workspaces.  The personal workspaces prevented developers
+%from stepping on each other's toes all the time, as was common with
+%SCCS and RCS.  Each developer had a copy of every project file, and
+%could modify their copies independently.  They had to merge their
+%edits prior to committing changes to the central repository.
 
-Later in the 1980s, Dick Grune used RCS as a building block for a set
-of shell scripts he initially called cmt, but then renamed to CVS
-(Concurrent Versions System).  The big innovation of CVS was that it
-let developers work simultaneously and somewhat independently in their
-own personal workspaces.  The personal workspaces prevented developers
-from stepping on each other's toes all the time, as was common with
-SCCS and RCS.  Each developer had a copy of every project file, and
-could modify their copies independently.  They had to merge their
-edits prior to committing changes to the central repository.
+1980年代後半にDick GruneはRCSを呼び出すシェルスクリプトによるバージョン管
+理システムを作った．初期にcmtと呼ばれたこのシステムは，後にCVS
+(Concurrent Versions System)と改名された． CVSの大きな革新は，開発者達に
+同時に個別のワークスペースで作業することを許したことである．ワークスペー
+スを個別にしたことで，開発者はSCCSやRCSで良くあったように，他の開発者の作
+業を妨げることがなくなった．このモデルでは，中央のリポジトリに変更をコミッ
+トする前に，変更結果をマージする必要があった．
+
+%Brian Berliner took Grune's original scripts and rewrote them in~C,
+%releasing in 1989 the code that has since developed into the modern
+%version of CVS.  CVS subsequently acquired the ability to operate over
+%a network connection, giving it a client/server architecture.  CVS's
+%architecture is centralised; only the server has a copy of the history
+%of the project.  Client workspaces just contain copies of recent
+%versions of the project's files, and a little metadata to tell them
+%where the server is.  CVS has been enormously successful; it is
+%probably the world's most widely used revision control system.
 
-Brian Berliner took Grune's original scripts and rewrote them in~C,
-releasing in 1989 the code that has since developed into the modern
-version of CVS.  CVS subsequently acquired the ability to operate over
-a network connection, giving it a client/server architecture.  CVS's
-architecture is centralised; only the server has a copy of the history
-of the project.  Client workspaces just contain copies of recent
-versions of the project's files, and a little metadata to tell them
-where the server is.  CVS has been enormously successful; it is
-probably the world's most widely used revision control system.
+Brian BerlinerはGruneのオリジナルスクリプトを受け継いで，それをCで書き直
+し，現在のCVSへと繋がるコードを1989年にリリースした．その後，CVSはネット
+ワークを経由した動作や，クライアントサーバアーキテクチャを備えていっ
+た．CVSのアーキテクチャは中央集中型で，サーバのみがプロジェクトの履歴を保
+存する．クライアントのワークスペースはプロジェクトの最新バージョンのファ
+イルのコピーであり，サーバの所在を示す僅かなメタデータが付加されていた．
+CVSは大成功を収め，おそらく世界で最も広く用いられたリビジョンコントロール
+システムとなった．
+
+%In the early 1990s, Sun Microsystems developed an early distributed
+%revision control system, called TeamWare.  A TeamWare workspace
+%contains a complete copy of the project's history.  TeamWare has no
+%notion of a central repository.  (CVS relied upon RCS for its history
+%storage; TeamWare used SCCS.)
 
-In the early 1990s, Sun Microsystems developed an early distributed
-revision control system, called TeamWare.  A TeamWare workspace
-contains a complete copy of the project's history.  TeamWare has no
-notion of a central repository.  (CVS relied upon RCS for its history
-storage; TeamWare used SCCS.)
+1990年代初頭，Sun MicrosystemsはTeamWareと呼ばれる初期の分散リビジョンコ
+ントロールシステムを開発した．TeamWareワークスペースはプロジェクトの履歴
+の完全なコピーを持っていた．TeamWareには中央リポジトリという概念はなかっ
+た．（CVSが履歴の記録にRCSを使っていたように，TeamWareはSCCSを用いてい
+た．）
+
+%As the 1990s progressed, awareness grew of a number of problems with
+%CVS.  It records simultaneous changes to multiple files individually,
+%instead of grouping them together as a single logically atomic
+%operation.  It does not manage its file hierarchy well; it is easy to
+%make a mess of a repository by renaming files and directories.  Worse,
+%its source code is difficult to read and maintain, which made the
+%``pain level'' of fixing these architectural problems prohibitive.
+
+1990年代中頃になると，CVSの問題が広く知られるようになってきた． CVSは一度
+に複数のファイルに対して行われる変更を論理的にアトミックな操作としてグルー
+プ化するのではなく，ファイル毎に個別に記録していた．CVSのファイルヒエラル
+キーの管理は不十分で，ファイルやディレクトリをリネームすると簡単にリポジ
+トリが混乱した．さらに悪いことに，CVSのソースコードは読みにくく，メンテナ
+ンスも難しかったため，アーキテクチャの問題を解決するのは不可能なレベルと
+言えた．
 
-As the 1990s progressed, awareness grew of a number of problems with
-CVS.  It records simultaneous changes to multiple files individually,
-instead of grouping them together as a single logically atomic
-operation.  It does not manage its file hierarchy well; it is easy to
-make a mess of a repository by renaming files and directories.  Worse,
-its source code is difficult to read and maintain, which made the
-``pain level'' of fixing these architectural problems prohibitive.
+%In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
+%CVS, started a project to replace it with a tool that would have a
+%better architecture and cleaner code.  The result, Subversion, does
+%not stray from CVS's centralised client/server model, but it adds
+%multi-file atomic commits, better namespace management, and a number
+%of other features that make it a generally better tool than CVS.
+%Since its initial release, it has rapidly grown in popularity.
+
+2001年，CVSを開発していたJim BlandyとKarl Fogelの2人の開発者がCVSを置き換
+える，より優れたアーキテクチャと奇麗なコードを持つツールのプロジェクトを
+始めた．その成果物であるSubversionはCVSの集中型クライアントサーバモデルを
+改めることはしなかったが，複数ファイルのアトミックなコミットを追加し，名
+前空間の管理も改良していた．またCVSよりも優れた数多くの機能も追加された．
+Subversionは最初のリリースから急速に人気を獲得していった．
 
-In 2001, Jim Blandy and Karl Fogel, two developers who had worked on
-CVS, started a project to replace it with a tool that would have a
-better architecture and cleaner code.  The result, Subversion, does
-not stray from CVS's centralised client/server model, but it adds
-multi-file atomic commits, better namespace management, and a number
-of other features that make it a generally better tool than CVS.
-Since its initial release, it has rapidly grown in popularity.
+%More or less simultaneously, Graydon Hoare began working on an
+%ambitious distributed revision control system that he named Monotone.
+%While Monotone addresses many of CVS's design flaws and has a
+%peer-to-peer architecture, it goes beyond earlier (and subsequent)
+%revision control tools in a number of innovative ways.  It uses
+%cryptographic hashes as identifiers, and has an integral notion of
+%``trust'' for code from different sources.
 
-More or less simultaneously, Graydon Hoare began working on an
-ambitious distributed revision control system that he named Monotone.
-While Monotone addresses many of CVS's design flaws and has a
-peer-to-peer architecture, it goes beyond earlier (and subsequent)
-revision control tools in a number of innovative ways.  It uses
-cryptographic hashes as identifiers, and has an integral notion of
-``trust'' for code from different sources.
+ほぼ時を同じくして，Graydon HoareはMonotoneと呼ばれる野心的な分散リビジョ
+ンコントロールシステムの開発を始めた．MonotoneはCVSの数多くの設計上の瑕疵
+を修正し，ピアツーピアアーキテクチャを持っている． Monotoneは初期の（ある
+いは後続の）リビジョンコントロールツールよりも先進的な機能を持ってい
+る．Monotoneは暗号化されたハッシュを識別子として使用し，様々な出処のコー
+ドに対して``信頼性''の概念を持っていた．
 
-Mercurial began life in 2005.  While a few aspects of its design are
-influenced by Monotone, Mercurial focuses on ease of use, high
-performance, and scalability to very large projects.
+%Mercurial began life in 2005.  While a few aspects of its design are
+%influenced by Monotone, Mercurial focuses on ease of use, high
+%performance, and scalability to very large projects.
 
-\section{Trends in revision control}
+Mercurialは2005年に誕生した．デザインのいくつかの面はMonotoneに影響を受け
+ているが，Mercurialは使いやすさ，高性能，大規模プロジェクトへのスケーラビ
+リティにフォーカスしている．
+
+%\section{Trends in revision control}
+\section{リビジョンコントロールのトレンド}
 
 There has been an unmistakable trend in the development and use of
 revision control tools over the past four decades, as people have
@@ -192,7 +321,8 @@
 autonomously, with a network connection only needed when syncing
 changes with another repository.
 
-\section{A few of the advantages of distributed revision control}
+%\section{A few of the advantages of distributed revision control}
+\section{分散リビジョンコントロールの利点}
 
 Even though distributed revision control tools have for several years
 been as robust and usable as their previous-generation counterparts,
@@ -226,7 +356,8 @@
 something that is relatively rare compared with local operations.  If
 you have a far-flung team of collaborators, this may be significant.
 
-\subsection{Advantages for open source projects}
+%\subsection{Advantages for open source projects}
+\subsection{オープンソースプロジェクトでの利点}
 
 If you take a shine to an open source project and decide that you
 would like to start hacking on it, and that project uses a distributed
@@ -241,7 +372,8 @@
 be at risk of corruption any time you try to update your client's view
 of the repository.
 
-\subsubsection{The forking non-problem}
+%\subsubsection{The forking non-problem}
+\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
@@ -288,7 +420,8 @@
 forgoing the ability to fluidly collaborate with whatever people feel
 compelled to mirror and fork your history.
 
-\subsection{Advantages for commercial projects}
+%\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
@@ -318,7 +451,8 @@
 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{Why choose Mercurial?}
+\section{Mercurialを選ぶ理由}
 
 Mercurial has a unique set of properties that make it a particularly
 good choice as a revision control system.
@@ -355,7 +489,8 @@
 useful extensions already available, ranging from helping to identify
 bugs to improving performance.
 
-\section{Mercurial compared with other tools}
+%\section{Mercurial compared with other tools}
+\section{Mercurialと他のツールの比較}
 
 Before you read on, please understand that this section necessarily
 reflects my own experiences, interests, and (dare I say it) biases.  I
@@ -501,7 +636,8 @@
 Mercurial can import revision history from a CVS repository.
 
 
-\subsection{Commercial tools}
+%\subsection{Commercial tools}
+\subsection{商用ツール}
 
 Perforce has a centralised client/server architecture, with no
 client-side caching of any data.  Unlike modern revision control
@@ -514,7 +650,8 @@
 proxies to cope with the load their users generate.
 
 
-\subsection{Choosing a revision control tool}
+%\subsection{Choosing a revision control tool}
+\subsection{リビジョンコントロールツールを選ぶ}
 
 With the exception of CVS, all of the tools listed above have unique
 strengths that suit them to particular styles of work.  There is no
@@ -532,7 +669,8 @@
 me well for several years.
 
 
-\section{Switching from another tool to Mercurial}
+%\section{Switching from another tool to Mercurial}
+\section{他のツールからMercurialへの移行}
 
 Mercurial is bundled with an extension named \hgext{convert}, which
 can incrementally import revision history from several other revision
@@ -561,7 +699,7 @@
 changes.
 
 
-%%% Local Variables: 
+%%% Local Variables:
 %%% mode: yatex
 %%% TeX-master: "00book"
-%%% End: 
+%%% End: