# HG changeset patch
# User Yoshiki Yazawa <yaz@honeyplanet.jp>
# Date 1238143164 -32400
# Node ID 2e072e3d86375381ba54ea1c5222949734877aab
# Parent  1604f2b2054b1fb6b23ef472a984794f54df7661
more intro.tex

diff -r 1604f2b2054b -r 2e072e3d8637 ja/intro.tex
--- a/ja/intro.tex	Sun Feb 22 00:48:17 2009 +0900
+++ b/ja/intro.tex	Fri Mar 27 17:39:24 2009 +0900
@@ -349,101 +349,130 @@
 %\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.
+%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.
+%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.
+%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.
+%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.
+%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.
+%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.
+%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.
 
-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.  
+%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.
 
-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:
-\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}
+%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:
+%\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}
 
-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.
+%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.
 
 %\subsection{Advantages for commercial projects}
 \subsection{商用プロジェクトでの利点}
@@ -517,10 +546,14 @@
 %\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.
+%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}
@@ -590,37 +623,64 @@
 
 \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 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 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.
+%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.
+%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.
 
-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.
+Mercurialリポジトリはメンテナンスを必要としないが，Gitリポジトリはしばし
+ば手動でメタデータの``repacks''が必要となる．これを行わない場合，性能は劣
+化し，必要な記憶領域も急速に拡大する．Gitリポジトリを規則正しく頻繁に
+repackしないサーバではバックアップの際にディスク使用が極めて多くなり，結
+果として毎日のバックアップに~24時間以上を費やすことになる．
+新規にpackされたGitリポジトリはMercurialリポジトリよりやや小さい
+が，unpack状態のGitリポジトリは数段大きくなる．
 
-Mercurial can import revision history from a Git repository.
+%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}
@@ -664,47 +724,75 @@
 %\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 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.
+%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.
+%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.
+%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.
 
-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.
+例えば，頻繁に変更されるバイナリファイルを扱う場合は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 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.
 
-The revision control tools supported by \hgext{convert} are as
-follows:
+Mercurialには\hgext{convert}という拡張が同梱されている．この拡張はリビジョ
+ン履歴を他のリビジョンコントロールツールからインクリメンタルにインポート
+する．「インクリメンタル」というのは，まずプロジェクトの履歴すべてを変換
+した後で，元のリポジトリに起きた変更をさらに変換して取り込めるという意味
+である．
+
+%The revision control tools supported by \hgext{convert} are as
+%follows:
+
+\hgext{convert}は次のリビジョンコントロールツールをサポートする:
 \begin{itemize}
 \item Subversion
 \item CVS
@@ -712,17 +800,25 @@
 \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.
+%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.
+%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