%\chapter{Introduction}
\chapter{導入}
\label{chap:intro}

%\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.

リビジョンコントロールとは，複数のバージョンの情報をを管理するプロセスで
ある．最も単純な方法は，ファイルを変更したら，それまでのバージョンよりも
大きな数字を含む新たな名前でセーブを行うなどの方法で全て手で行うことであ
る．

%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.

たった一つのファイルに対しても，複数のバージョンを手で管理することは間違
いを起こし易い作業で，このプロセスを自動化するソフトウェアツールがかなり
の昔から提供されてきた．最初の自動化されたリビジョンコントロールツール
は，一人のユーザを対象として，1つのファイルのリビジョンを管理するために作
られた．数十年が経ち，リビジョンコントロールの取り扱うスコープは大いに拡
大した．今では複数人による複数ファイルの編集をも管理することができる．現
代の最高のリビジョン管理ツールは数千人による，数十万個のファイルを擁する
プロジェクトにも対応する．

%\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 リビジョン管理ツールは，プロジェクトの履歴と進化を記録するため，自
       分自身で記録する必要がない．全ての変更に対して\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.
これらの理由の多くは自分自身のプロジェクトで作業していても，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.

リビジョンコントロールの実用性に関する鍵になる質問は，これらの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.

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はこれらの開発スケールの両方をサポートしている．基礎的な使用法は
数分で学ぶことができ，リビジョンコントロールを最小規模のプロジェクトに簡
単に取り入れることができる．単純であるため，難解なコンセプトやコマンドシー
ケンスに意識の多くを占められ，本当にやりたいことが疎かになることもない．
また同時に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.

お粗末なプロジェクトを救済するようなリビジョンコントロールは存在しない
が，良いツールの選択は，作業するプロジェクトの堅実さに大きな差をもたらす．

%\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:
リビジョンコントロールは大きな幅をもつ分野であり，そのため多くの呼び名と
その短縮形が知られている：
\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))
\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.
これらの用語は各々違う意味を持つのだと主張する人々もいる．しかし実質的に
はこれらは互いに大きく重なっており，わざわざ区別することは一般的でなく，
また有用でもない．

%\section{A short history of revision control}
\section{リビジョンコントロールの歴史}

%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
は個々のファイルに対して動作し，プロジェクトの共同作業者には同一マシン上
の共有ワークスペースへのアクセスが必要であった．ファイルへのアクセスの調
停はロックによって行われ，あるファイルを変更できるのは常に一人のユーザだ
けであった．ファイルをロックした後，ロックの解除を忘れることは日常的にあ
り，こうなると管理者の助けなしに他の開発者がファイルを変更することはでき
なかった．

%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は開発者たちに単一の共有ワークスペースと，ファイルを同
時に複数人が変更することのないようにロックを要求した．

%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は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.)

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のソースコードは読みにくく，メンテナ
ンスも難しかったため，アーキテクチャの問題を解決するのは不可能なレベルと
言えた．

%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は最初のリリースから急速に人気を獲得していった．

%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は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
%become familiar with the capabilities of their tools and constrained
%by their limitations.

リビジョンコントロールツールの開発と使用において，過去20年間ツールに親し
み，ツールの制限を知るに従って，紛れもないトレンドが存在している．

%The first generation began by managing single files on individual
%computers.  Although these tools represented a huge advance over
%ad-hoc manual revision control, their locking model and reliance on a
%single computer limited them to small, tightly-knit teams.

第一世代のツールは単一のファイルを個別のコンピュータの上で管理した．アド
ホックな手動によるリビジョンコントロールと比べて大幅な進歩があったが，ロッ
クモデルと単一コンピュータへの依存のため，利用は小規模で緊密なチームに限
られた．

%The second generation loosened these constraints by moving to
%network-centered architectures, and managing entire projects at a
%time.  As projects grew larger, they ran into new problems.  With
%clients needing to talk to servers very frequently, server scaling
%became an issue for large projects.  An unreliable network connection
%could prevent remote users from being able to talk to the server at
%all.  As open source projects started making read-only access
%available anonymously to anyone, people without commit privileges
%found that they could not use the tools to interact with a project in
%a natural way, as they could not record their changes.

第二世代のツールは，ネットワーク中心のアーキテクチャに移行することで，そ
れまでの制限を緩和し，プロジェクト全体を同時に管理した．プロジェクトが大
きく成長すると，新たな問題に直面した．クライアントがサーバに頻繁に通信す
るため，大規模プロジェクトではサーバの規模が問題になった．信頼性のないネッ
トワーク接続はリモートユーザがサーバと通信するのを妨げた．オープンソース
プロジェクトがコミット権のないユーザにも匿名の読み出し専用アクセスを提供
するようになると，ツールは彼らの行った変更を記録できないため，プロジェク
トとやりとりを行う自然な手段とは言えないことがわかった．

%The current generation of revision control tools is peer-to-peer in
%nature.  All of these systems have dropped the dependency on a single
%central server, and allow people to distribute their revision control
%data to where it's actually needed.  Collaboration over the Internet
%has moved from constrained by technology to a matter of choice and
%consensus.  Modern tools can operate offline indefinitely and
%autonomously, with a network connection only needed when syncing
%changes with another repository.

現行世代のリビジョンコントロールツールは，ピアツーピアである．これらのシ
ステムの全てが単一の中央サーバへ依存しなくなっており，リビジョンコントロー
ルデータを必要なところへ分散させることができるようになっている．インター
ネットを通じた共同作業は技術的制約から離れて，選択と合意によって行われる
ようになった．現代のツールはオフラインのままでも，自律的にも動作するよう
になっている．ネットワーク接続は変更を別のリポジトリと同期させる時にのみ
必要である．

%\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,
%people using older tools have not yet necessarily woken up to their
%advantages.  There are a number of ways in which distributed tools
%shine relative to centralised ones.

分散リビジョンコントロールツールはもう数年も前から前世代のツールと同様に
堅牢かつ有用なものと認められているにもかかわらず，古いツールのユーザたち
はその利点を知らない．分散ツールが中央集中ツールよりも優れいている点は多々
ある．

%For an individual developer, distributed tools are almost always much
%faster than centralised tools.  This is for a simple reason: a
%centralised tool needs to talk over the network for many common
%operations, because most metadata is stored in a single copy on the
%central server.  A distributed tool stores all of its metadata
%locally.  All else being equal, talking over the network adds overhead
%to a centralised tool.  Don't underestimate the value of a snappy,
%responsive tool: you're going to spend a lot of time interacting with
%your revision control software.

個人の開発者にとっては，分散ツールはほとんどの場合，中央集中ツールよりも
高速である．その理由は，中央集中ツールではほとんどのメタデータは中央サー
バで単一コピーとして保管されており，通常のオペレーションの多くをネットワー
クを経由して行う必要があるからだ．分散ツールは全てのメタデータをローカル
に保存する．その他も同様で，中央集中ツールはネットワーク越しの通信によっ
てオーバヘッドを生じる．開発中，リビジョンコントロールソフトウェアの操作
を幾度となく行うことを考えれば，ツールの僅かなオーバヘッドでも過小評価す
べきではない．

%Distributed tools are indifferent to the vagaries of your server
%infrastructure, again because they replicate metadata to so many
%locations.  If you use a centralised system and your server catches
%fire, you'd better hope that your backup media are reliable, and that
%your last backup was recent and actually worked.  With a distributed
%tool, you have many backups available on every contributor's computer.

分散ツールはメタデータを様々な場所に複製するため，サーバインフラストラク
チャの障害に関わりなく動作する．もし中央集中システムを使っていて，サーバ
が火災にあったとしたら，信頼できるバックアップメディアに最近作成したバッ
クアップコピーが残っており，それがまともに機能することを祈ることになる．
分散ツールでは，協力者のコンピュータの中に数多くのバックアップが残されて
いる．

%The reliability of your network will affect distributed tools far less
%than it will centralised tools.  You can't even use a centralised tool
%without a network connection, except for a few highly constrained
%commands.  With a distributed tool, if your network connection goes
%down while you're working, you may not even notice.  The only thing
%you won't be able to do is talk to repositories on other computers,
%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{オープンソースプロジェクトでの利点}

%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
%revision control tool, you are at once a peer with the people who
%consider themselves the ``core'' of that project.  If they publish
%their repositories, you can immediately copy their project history,
%start making changes, and record your work, using the same tools in
%the same ways as insiders.  By contrast, with a centralised tool, you
%must use the software in a ``read only'' mode unless someone grants
%you permission to commit changes to their central server.  Until then,
%you won't be able to record changes, and your local modifications will
%be at risk of corruption any time you try to update your client's view
%of the repository.

オープンソースプロジェクトが好きになり，作業を始めようとするとき，プロジェ
クトが分散リビジョンコントロールツールを使っていれば，ただちにプロジェク
トのコアメンバーの仲間となる．彼らがリポジトリを公開していれば，直ちにプ
ロジェクト履歴をコピーし，変更を行い，内部のメンバーが使っているのと全く
同じツールを用いて作業結果を記録することができる．対称的にメンバーが中央
集中型のツールを使っている場合，誰かがあなたに変更を中央のサーバにコミッ
トする許可を与えない限り，ツールをリードオンリーモードで使用することにな
る．それまでは変更を記録することはできず，あなたのローカルな変更はリポジ
トリのクライアントコピーを更新するたびに破壊されるリスクを伴う．

%\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
%``fork'' the development of a project.  A fork happens when there are
%differences in opinion or attitude between groups of developers that
%cause them to decide that they can't work together any longer.  Each
%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
%by hand.  You have to decide whose revision history is going to
%``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
%approach is that a distributed revision control tool has to be really
%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
%  outsiders (people without).
%\item They make it easier to reconcile after a social fork, because
%  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
%give them this control.  However, if you're of this belief, and you
%publish your CVS or Subversion repositories publically, there are
%plenty of tools available that can pull out your entire project's
%history (albeit slowly) and recreate it somewhere that you don't
%control.  So while your control in this case is illusory, you are
%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.

商用プロジェクトの多くは地理的に広がったチームによって開発されている．中
央サーバは，遠く離れた協力者からはコマンド実行が遅かったり，信頼性が低かっ
たりするように見える．商用リビジョンコントロールシステムはこの問題の解決
にリモートサイトの複製を作成するアドオンを提供している．これらの多くは高
価だったり，管理が複雑だという問題を持っている．分散システムにはそもそも
これらの問題がない．さらに好ましいことに，複数のサイト毎に正式なサーバを
簡単に設定することができ，高価な長距離のネットワークリンク上に冗長な通信
を行うことがない．

%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.

顧客の側でこの領域の問題解決を行う従業員がいれば，分散リビジョンコントロー
ルの利益を得ることができる．ツールを使うことで，カスタムビルド，互いに独
立した修正のテスト，プロジェクトの履歴からバグやリグレッションの原因の探
索などを顧客の環境でネットワークに接続する必要なく実現できる．

%\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は，リビジョンコントロールシステムとして選択するのにふさわしい
ユニークな性質を持っている．
\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 学習と利用が簡単
\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.

読者がリビジョンコントロールに慣れているのであれば， 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.

小さなプロジェクトでは，すぐに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.

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.

Mercurialの核になる機能が十分でなかった場合，拡張することはたやすい．
Mercurialはスクリプトとよく馴染む．また整った内部構造とPythonによる実装の
ため，拡張の形で新しい機能を追加するのが容易である．バグの識別を助けるも
のから，性能を改善するものまで，人気の高い有用な拡張がすでに数多く存在し
ている．

%\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
%have used every one of the revision control tools listed below, in
%most cases for several years at a time.

この節を読む前に，これは筆者自身の体験と興味，そして（敢えて言えば）バイ
アスがかかっていることを理解して欲しい．筆者は下記のリビジョンコントロー
ルツールのすべてを使用したことがあり，その使用期間は多くの場合数年に及ぶ．

\subsection{Subversion}

%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と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は履歴を考慮したマージの機能を欠いており，正確にどのリビジョン
がブランチ間でマージされたのかユーザ自身がトラックする必要がある。ユーザ
が追い切れなかった場合や間違いを犯した場合，必要のないコンフリクトを手動
で解決することになる．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は筆者がベンチマークを行った全てのリビジョンコントロール操作にお
いて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.

さらに，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には多くのサードパーティツールがある．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.

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.

加えて，異なるバージョンのバイナリファイルをマージするのは不可能であった
り，困難であったりする． 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はSubversionリポジトリからリビジョン履歴をインポートすることがで
きる．また，リビジョン履歴をSubversionリポジトリにエクスポートすることも
可能だ．このため，移行を決める前にMercurialを試したり，Mercurialを
Subversionと並行して利用することが容易である．
履歴の変換は漸進的に行えるため，最初に変換を行った後，新たな変更を取り込
むために追加の変換を行うことができる．

\subsection{Git}

%Git is a distributed revision control tool that was developed for
%managing the Linux kernel source tree.  Like Mercurial, its early
%design was somewhat influenced by Monotone.

GitはLinuxカーネルのソースツリーを扱うために開発された分散リビジョンコン
トロールツールである． Mercurial同様，その初期のデザインは多少Monotoneに
影響を受けている．

%Git has a very large command set, with version~1.5.0 providing~139
%individual commands.  It has something of a reputation for being
%difficult to learn.  Compared to Git, Mercurial has a strong focus on
%simplicity.

Gitは非常に大規模なコマンドセットを持っている．version~1.5.0では~139にも
及ぶコマンドが用意されている．このため，Gitはしばしば習得しづらいという
評判されている．MercurialはGitと比べると簡潔さに強くフォーカスしている．

%In terms of performance, Git is extremely fast.  In several cases, it
%is faster than Mercurial, at least on Linux, while Mercurial performs
%better on other operations.  However, on Windows, the performance and
%general level of support that Git provides is, at the time of writing,
%far behind that of Mercurial.

性能に関しては，Gitは極めて高速である．Linux環境でのテストでは，いくつか
の操作はGitはMercurialよりも高速であった．しかしWindows環境では，この本の
執筆時点では，性能やGitの提供する機能はMercurialに大きく劣った．

%While a Mercurial repository needs no maintenance, a Git repository
%requires frequent manual ``repacks'' of its metadata.  Without these,
%performance degrades, while space usage grows rapidly.  A server that
%contains many Git repositories that are not rigorously and frequently
%repacked will become heavily disk-bound during backups, and there have
%been instances of daily backups taking far longer than~24 hours as a
%result.  A freshly packed Git repository is slightly smaller than a
%Mercurial repository, but an unpacked repository is several orders of
%magnitude larger.

Mercurialリポジトリはメンテナンスを必要としないが，Gitリポジトリはしばし
ば手動でメタデータの``repacks''が必要となる．これを行わない場合，性能は劣
化し，必要な記憶領域も急速に拡大する．Gitリポジトリを規則正しく頻繁に
repackしないサーバではバックアップの際にディスク使用が極めて多くなり，結
果として毎日のバックアップに~24時間以上を費やすことになる．
新規にpackされたGitリポジトリはMercurialリポジトリよりやや小さい
が，unpack状態のGitリポジトリは数段大きくなる．

%The core of Git is written in C.  Many Git commands are implemented as
%shell or Perl scripts, and the quality of these scripts varies widely.
%I have encountered several instances where scripts charged along
%blindly in the presence of errors that should have been fatal.

GitのコアはCで書かれている．Gitコマンドの多くはシェルやPerlのスクリプトと
して実装されており，それらのスクリプトの品質は様々である．数度にわたって
致命的なエラーがあるにもかかわらず，スクリプトが盲滅法に動作することを体
験した．

%Mercurial can import revision history from a Git repository.

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はおそらく世界中で最も広範に使用されているリビジョンコントロールツー
ルであろう．その古さと内部の乱雑さのため，長らく軽いメンテナンスのみが行
われてきた．

%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のタグとブランチは語る気さえ起きないような混乱した形式を持っている．き
ちんとしたファイルやディレクトリのリネームをサポートしないため，リポジト
リが簡単に壊れてしまう． 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はCVSのリビジョン履歴をインポートすることができる．しかし他のリ
ビジョンコントロールツールのCVSインポーター同様いくつかの制限もある．
CVSにはアトミックチェンジがなく，ファイルシステム階層をバージョン管理す
る能力もないため，CVSの履歴を完全かつ正確に再現することはできない．再現
にはいくつかの推測が入り，リネームは通常再現されない．
CVSでは高度な管理の多くが手動で行われるため，間違いが起こりやすく，破損し
たリポジトリでCVSインポーターが同時に複数の問題に見舞われることがよくあ
る．（筆者の不愉快な体験では，10年以上にわたってロックされたままの完全に
無意味なリビジョンタイムスタンプやファイルを見たことがある．）

%Mercurial can import revision history from a CVS repository.

MercurialはCVSリポジトリからリビジョン履歴をインポートすることができる．

%\subsection{Commercial tools}
\subsection{商用ツール}

%Perforce has a centralised client/server architecture, with no
%client-side caching of any data.  Unlike modern revision control
%tools, Perforce requires that a user run a command to inform the
%server about every file they intend to edit.

Perforceは集中型のクライアント・サーバアーキテクチャを持ち，いかなるデー
タもクライアント側でキャッシュしない．現在のリビジョンコントロールツール
とことなり，Perforceではユーザがどのファイルを編集するのかサーバに知らせ
るコマンドを実行する必要がある．

%The performance of Perforce is quite good for small teams, but it
%falls off rapidly as the number of users grows beyond a few dozen.
%Modestly large Perforce installations require the deployment of
%proxies to cope with the load their users generate.

Perforceの性能は，小規模なチームでの作業においてはかなり良い．しかしユー
ザ数が数ダース以上に増加するに従って，急激に悪くなっていく．かなり大規模
なPerforce環境では，ユーザの操作による負荷を軽減するためのプロキシーが必
要になる．

%\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
%single revision control tool that is best in all situations.

CVSを除いて，上記のツールは特定の作業スタイルに合った固有の強みを持ってい
る．すべての状況でベストであるツールというものは存在しない．

%As an example, Subversion is a good choice for working with frequently
%edited binary files, due to its centralised nature and support for
%file locking.  If you're averse to the command line, it currently has
%better GUI support than other free revision control tools.  However,
%its poor merging is a substantial liability for busy projects with
%overlapping development.

例えば，頻繁に変更されるバイナリファイルを扱う場合はSubverrsionを選ぶのが
良い．Subversionの集中型の性質とファイルロックのサポートはバイナリファイ
ルの取り扱いに適している．コマンドラインが嫌いならば，他のフリーリビジョ
ン管理ツールよりも優れたGUIサポートがある．しかしマージ機構の弱さは同時に
並行した開発では少なからぬ問題となりうる．

%I personally find Mercurial's properties of simplicity, performance,
%and good merge support to be a compelling combination that has served
%me well for several years.

個人的には，数年にわたって，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
%control tools.  By ``incremental'', I mean that you can convert all of
%a project's history to date in one go, then rerun the conversion later
%to obtain new changes that happened after the initial conversion.

Mercurialには\hgext{convert}という拡張が同梱されている．この拡張はリビジョ
ン履歴を他のリビジョンコントロールツールからインクリメンタルにインポート
する．「インクリメンタル」というのは，まずプロジェクトの履歴すべてを変換
した後で，元のリポジトリに起きた変更をさらに変換して取り込めるという意味
である．

%The revision control tools supported by \hgext{convert} are as
%follows:

\hgext{convert}は次のリビジョンコントロールツールをサポートする:
\begin{itemize}
\item Subversion
\item CVS
\item Git
\item Darcs
\end{itemize}

%In addition, \hgext{convert} can export changes from Mercurial to
%Subversion.  This makes it possible to try Subversion and Mercurial in
%parallel before committing to a switchover, without risking the loss
%of any work.

加えて，\hgext{convert}はMercurialからSubversionに変更をエクスポートする
ことができる．これにより，SubversionからMercurialに切替える前に，行った作
業の結果を失うことなく，両者を並行して試すことができる．

%The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
%at the path or URL of the source repository, optionally give it the
%name of the destination repository, and it will start working.  After
%the initial conversion, just run the same command again to import new
%changes.

\hgxcmd{conver}{convert}コマンドを使うのはたやすい．単にソースリポジトリ
のパスやURLを渡すだけで，使用可能なリポジトリを作成する．また，オプション
で変換後のリポジトリの名前を渡すこともできる．最初の変換後，同じコマンド
を再び実行すると新しい変更を取り込むことができる．

%%% Local Variables:
%%% mode: yatex
%%% TeX-master: "00book"
%%% End:
