foozy@708: \chapter{Introduction} foozy@708: \label{chap:intro} foozy@708: foozy@708: \section{About revision control} foozy@708: foozy@708: 構成管理とは、 foozy@708: 複数の版を持つ情報群を管理する手順のことです。 foozy@708: 最も単純な手法では、 foozy@708: 多くの人々がこれを手動で行います。 foozy@708: ファイル更新時には、 foozy@708: 直前の版に利用した値よりも大きな値を割り当ててから、 foozy@708: その値を含めた新しい名前でファイルを保存する、 foozy@708: といった具合です。 foozy@708: foozy@708: しかしながら、たった1つのファイルであっても、 foozy@708: 複数の版を手動で管理する作業は間違いがちですので、 foozy@708: この手順を自動化するソフトウェアツールには長い歴史があります。 foozy@708: 初期の構成管理を自動化するツールは、 foozy@708: 単一ユーザによる単一ファイルの版管理の補助を意図していました。 foozy@708: ここ数十年の間に、 foozy@708: 構成管理ツールの適用範囲は大変拡大されてきました。 foozy@708: 現在では、 foozy@708: 複数のファイルに対する複数のユーザの共同作業を管理するまでになっています。 foozy@708: 今時の最善の構成管理ツールは、 foozy@708: 共同作業する数千人のユーザによって、 foozy@708: 数十万のフィルからなるプロジェクトのデータが複製されても、 foozy@708: びくともしません。 foozy@708: foozy@708: \subsection{Why use revision control?} foozy@708: foozy@708: プロジェクトにおいて、読者であるあなたや、 foozy@708: あなたのチームが自動化された構成管理ツールを使用したくなるのは、 foozy@708: 以下のような理由があるからではないでしょうか。 foozy@708: foozy@708: \begin{itemize} foozy@708: \item プロジェクトの歴史と発展を記録してくれるので、 foozy@708: 自分でそれを記録する必要が無いため。 foozy@708: 構成管理ツールを使用することで、 foozy@708: 変更毎に、\emph{何時}、\emph{誰が}、\emph{何故}、 foozy@708: \emph{何を}変更したかの記録を見ることができます。 foozy@708: foozy@708: \item 他のメンバーとの共同作業が容易になるため。 foozy@708: 例えば、潜在的に両立しない変更がほぼ同時に行われた際に、 foozy@708: 構成管理ツールはそのことを検出した上で、 foozy@708: このような衝突の解消を手助けしてくれます。 foozy@708: foozy@708: \item 間違いからの復旧を手助けしてくれるため。 foozy@708: 変更実施した後で間違いに気付いた場合、 foozy@708: 複数のファイルに渡る間違いであっても、 foozy@708: 以前の状態に復旧することができます。 foozy@708: 実のところ、 foozy@708: \emph{本当に}良い構成管理ツールであれば、 foozy@708: 問題が混入した時点の厳密な割り出しを効果的に探し出すことができるでしょう foozy@708: (詳細は、\ref{sec:undo:bisect}~節を参照してください)\footnote{訳注: foozy@708: つまり、それができる Mercurial は\emph{本当に}良い構成管理ツールだ、 foozy@708: ということですね(笑)}。 foozy@708: foozy@708: \item プロジェクトの複数の版の間での同時作業や、 foozy@708: 版の間での行き来を補助してくれるため。 foozy@708: foozy@708: \end{itemize} foozy@708: foozy@708: これらの理由の殆どが--- foozy@708: 少なくとも理屈の上では foozy@708: ---一人きりのプロジェクトでも、 foozy@708: 百人と共同作業するプロジェクトでも有効です。 foozy@708: foozy@708: これら2つの規模の異なるケース foozy@708: (``lone hacker'' と ``huge team'')のそれぞれにおいて、 foozy@708: 構成管理ツールの実用性に関する重要な問題は、 foozy@708: ツールから得られる\emph{利益}とその\emph{コスト}をどのように比較するか、 foozy@708: という点にあります。 foozy@708: 理解や使用が難しい構成管理ツールは、 foozy@708: コストが高く付くでしょう。 foozy@708: foozy@708: 構成管理のツールとプロセス抜きでは、 foozy@708: 500 人からなるプロジェクトはおそらく自分自身の重みで、 foozy@708: すぐにでも崩れてしまうでしょう。 foozy@708: この場合、 foozy@708: 構成管理ツール\emph{抜き}には失敗が保証されたようなものですから、 foozy@708: それを思えば、 foozy@708: 構成管理ツールを利用するコストについては考えるまでも無いでしょう。 foozy@708: foozy@708: 一方で、一人での``quick hack''の場合、 foozy@708: 構成管理ツールを使うコストはプロジェクト全体のコストと同一の筈ですから、 foozy@708: 構成管理を使う余地は殆ど無いように見えるかもしれません。 foozy@708: しかし、それは本当でしょか? foozy@708: foozy@708: Mercurial はこれら\emph{両方}の規模の開発を上手にサポートします。 foozy@708: わずか数分で基本を習得でき、 foozy@708: その低オーバヘッドのお陰で foozy@708: 最も小さなプロジェクトにも簡単に構成管理を適用できます。 foozy@708: foozy@708: 構成管理ツールの単純さは、 foozy@708: 難解な概念や、 foozy@708: \emph{本当に}やろうとしていることと心理的に競合するコマンド列といったものを、 foozy@708: 大量に身に付ける必要が無いことを意味します。 foozy@708: 同時に、 foozy@708: Mercurial の高性能さと P2P 的特性は、 foozy@708: 大きなプロジェクトへの利用へと苦も無く拡大できます。 foozy@708: foozy@708: 運営の下手なプロジェクトを救える構成管理ツールはありませんが、 foozy@708: 良いツールを選択することで、 foozy@708: プロジェクトでの作業における滑らかさが全く違ってきます。 foozy@708: foozy@708: \subsection{The many names of revision control} foozy@708: foozy@708: 構成管理は多様な領域なので、 foozy@708: 実際には統一された名前や頭字語語がありません。 foozy@708: foozy@708: よく目にする一般的な名称および略称を以下に列挙します。 foozy@708: foozy@708: \begin{itemize} foozy@708: \item Revision control (RCS) foozy@708: \item Software configuration management (SCM), or configuration management foozy@708: \item Source code management foozy@708: \item Source code control, or source control foozy@708: \item Version control (VCS) foozy@708: \end{itemize} foozy@708: foozy@708: これらの用語は実際にはそれぞれ異なる意味を持っている、 foozy@708: と主張する人もいますが、 foozy@708: 実際にはお互いに非常に重複した意味を持っているので、 foozy@708: これらに対して個別にあれこれ言うことには賛同もできませんし、 foozy@708: 有用性もありません\footnote{訳注: foozy@708: 昨今のソフトウェア開発における用法を鑑みて、 foozy@708: 原文で ``revision control'' となっている箇所は、 foozy@708: 意図的に``構成管理''(configuration management)と訳しています。}。 foozy@708: foozy@708: \section{A short history of revision control} foozy@708: foozy@708: 最も有名な昔の構成管理ツールは、 foozy@708: Bell Labs の Marc Rochkind が 1970 年代初頭に実装した foozy@708: SCCS (Source Code Control System)です。 foozy@708: SCCS は個別のファイルに対して機能し、 foozy@708: プロジェクトに従事する全ての作業者は、 foozy@708: 単一システム上の共有作業領域へのアクセス権が必要でした。 foozy@708: ある時点でのあるファイルの変更は、ただ一人の作業者のみが可能で、 foozy@708: ファイルのアクセスはロックにより調停されていました。 foozy@708: ファイルをロックしたまま開放し忘れてしまい、 foozy@708: 管理者の補助無しには他の人がファイルを変更できなくしてしまうことは、 foozy@708: 良くあることでした。 foozy@708: foozy@708: SCCS のフリーな代替ツールとして foozy@708: 1980 年代初頭に Walter Tichy が foozy@708: RCS (Revison Control System)と呼ぶプログラムを開発しました。 foozy@708: SCCS と同様、 foozy@708: RCS の利用には、 foozy@708: 単一の共有作業領域での作業と、 foozy@708: 複数の作業者が同時に改変するのを防ぐためのロックが必要でした。 foozy@708: foozy@708: 1980 年代後期、Dick Grune は RCS を用いて、 foozy@708: 当初 cmt と呼ばれるシェルスクリプト群を実装し、 foozy@708: 後にこれらは CVS (Concurrent Versions System)と改名されました。 foozy@708: CVS における大きな変革は、 foozy@708: 各開発者ごとの作業領域において、 foozy@708: 開発者が平行且つ幾分独立した作業ができるようになったことです。 foozy@708: SCCS や RCS では良くあった、 foozy@708: いつでも他人の足を踏んでしまう状況が、 foozy@708: 開発者ごとの作業領域の導入によって防がれるようになりました。 foozy@708: 各開発者は、 foozy@708: プロジェクトに関する全てのファイルの複製を持ち、 foozy@708: 各自の複製を独立して変更することができました。 foozy@708: 中央のリポジトリへの変更のコミットに先立って、 foozy@708: 変更内容のマージをする必要がありました。 foozy@708: foozy@708: Brian Berliner は foozy@708: Grune のオリジナルスクリプトを元に C で書き直し、 foozy@708: 以来現代版の CVS へと発展するコードを 1989 にリリースしました。 foozy@708: CVS はその後、 foozy@708: 「クライアント・サーバ」アーキテクチャの導入により、 foozy@708: ネットワーク接続越しの操作を可能とする機能を獲得しました。 foozy@708: CVS のアーキテクチャは中央集約的なもので、 foozy@708: サーバのみがプロジェクトの履歴のこぴーを持っています。 foozy@708: クライアント側の作業領域は、 foozy@708: プロジェクトファイルの最新版を複製したものと、 foozy@708: サーバの場所等を知るためのわずかなメタデータを持っているだけです。 foozy@708: CVS は非常に成功していて、 foozy@708: おそらく世界で最も広く使用されている構成管理システムでしょう。 foozy@708: foozy@708: Sun Microsystems は 1990 年代初頭に、 foozy@708: TeamWare と呼ばれる分散構成管理システムのはしりとなるものを開発しました。 foozy@708: TeamWare における(個人の)作業領域は、 foozy@708: プロジェクトの完全な複製を格納しています。 foozy@708: TeamWare には「中央リポジトリ」という概念がありません foozy@708: (CVS は履歴格納を RCS に依存していましたが、 foozy@708: TeamWare は SCCS を利用していました)。 foozy@708: foozy@708: 1990 年代が進むにつれて、 foozy@708: 問題意識から CVS に関する問題が多く顕在化してきました。 foozy@708: 例えば CVS は、 foozy@708: 複数のファイルに対する同時更新を、 foozy@708: 論理的に不可分な単一の作用としてまとめる替わりに、 foozy@708: ファイルごとに個別に記録しています。 foozy@708: また、ファイル階層を上手く管理できないため、 foozy@708: ファイルやディレクトリを改名することで、 foozy@708: 容易にリポジトリを混乱させることができます。 foozy@708: なお悪いことに、 foozy@708: CVS 自身のソースコードは読むにも保守するにも難解なため、 foozy@708: アーキテクチャ上の問題点を修正する``苦痛度''は法外なものでした。 foozy@708: foozy@708: CVS の開発を行っていた foozy@708: Jim Blandy および Karl Fogel の二人は、 foozy@708: より良いアーキテクチャを持ち、 foozy@708: 尚且つコードが綺麗なツールで CVS を置き換えるプロジェクトを、 foozy@708: 2001 年に始めました。 foozy@708: 結果として生み出された Subversion は、 foozy@708: CVS の中央集約型クライアント/サーバモデルからは離れなかったものの、 foozy@708: 複数ファイルの不可分コミットや、 foozy@708: より良い名前空間の管理、 foozy@708: および CVS よりも概ね良好なツールと言うに足るその他の多くの機能を持っています。 foozy@708: 初回のリリース以来、その人気は速やかに上昇しています。 foozy@708: foozy@708: それと概ね同時期に、 foozy@708: Graydon Hoare は Monotone foozy@708: と呼ばれる野心的な分散構成管理システムに取り掛かり始めました。 foozy@708: Monotone は、 foozy@708: CVS 設計上の多くの問題に取り組み、P2P アーキテクチャを持つ一方で、 foozy@708: 多くの革新的な点において初期の(そしてその後の) foozy@708: 構成管理ツールから飛び抜けています。 foozy@708: Monotone は、 foozy@708: 暗号で用いられるハッシュ値を識別子として使用しており、 foozy@708: 異なる由来のコードにとって不可欠な``信頼''の概念を持っています。 foozy@708: foozy@708: Mercurial は 2005 年に誕生しました。 foozy@708: 設計上の幾つかの見地において Monotone から影響を受ける一方で、 foozy@708: Mercurial は利用の簡便性、性能の高さ、 foozy@708: および大規模プロジェクトへの適用性に主眼を置いています。 foozy@708: foozy@708: \section{Trends in revision control} foozy@708: foozy@708: 過去40年に渡る構成管理ツールの開発と利用における紛れも無い傾向として、 foozy@708: 構成管理ツールの利用者は、 foozy@708: 利用しているツールの機能に精通すると共に、 foozy@708: ツールの制約によって抑制されるようです。XXXXXX foozy@708: There has been an unmistakable trend in the development and use of foozy@708: revision control tools over the past four decades, as people have foozy@708: become familiar with the capabilities of their tools and constrained foozy@708: by their limitations. foozy@708: foozy@708: 最初の世代は、 foozy@708: 単一ファイルを各自のコンピュータで管理することから始まりました。 foozy@708: この世代のツールは、 foozy@708: 手動による場当たりな構成管理に比べれば大きな前進ではありましたが、 foozy@708: 排他による操作モデルと、 foozy@708: 単一コンピュータ上での利用を前提とした設計のため、 foozy@708: 小さく緊密なチームでの利用に限定されていました。 foozy@708: foozy@708: 第二世代は、 foozy@708: ネットワーク主体のアーキテクチャへの移行と、 foozy@708: プロジェクト全体の一括管理によって、 foozy@708: これらの制約を緩和しました。 foozy@708: しかし、プロジェクト規模が大きくなればなるほど、新たな問題が発生しました。 foozy@708: クライアントはサーバと頻繁に連携する必要があるため、 foozy@708: サーバは大規模プロジェクトへの適用が問題になりました。 foozy@708: 信頼性の低いネットワーク接続では、 foozy@708: 遠隔ユーザがサーバと全く連携ができないこともありました。 foozy@708: オープンソースプロジェクトが匿名の読み込み専用アクセスを開放するにつれ、 foozy@708: リポジトリへのコミット権限を持たない人々は、 foozy@708: 構成管理ツールの通常の方法では自分たちの変更が記録できず、 foozy@708: それ故にプロジェクトに対して働きかけることができないことに気付き始めました。 foozy@708: foozy@708: 現世代の構成管理ツールは、事実上 P2P です。 foozy@708: これらは、 foozy@708: 単一の中央サーバに対する依存を持たず、 foozy@708: そのため構成管理データを必要な場所に分散することが可能です。 foozy@708: インターネットを介した連携における課題は、 foozy@708: 技術的な制約に関するものから、 foozy@708: 選択(of what ?)と合意(of what)形成の問題へと移行しつつあります XXXX。 foozy@708: Collaboration over the Internet foozy@708: has moved from constrained by technology to a matter of choice and foozy@708: consensus. foozy@708: 最新のツールは、 foozy@708: オフライン状況でも無制限に独立して操作でき、 foozy@708: ネットワーク接続は他のリポジトリとの同期にのみ必要とされます。 foozy@708: foozy@708: \section{A few of the advantages of distributed revision control} foozy@708: foozy@708: 前世代への対抗馬として、 foozy@708: ここ数年の間に分散構成管理ツールが堅牢且つ便利になってきてはいるものの、 foozy@708: 古いツールを利用している人々は、 foozy@708: 必ずしも分散構成管理ツールの長所に気付いているわけではありません。 foozy@708: 中央集約的型(ツール)と比較して、 foozy@708: 分散型(ツール)の優れている点が幾つかあります。 foozy@708: foozy@708: 開発者個人にとっては、 foozy@708: 中央集約型と比較した場合、 foozy@708: 概ねいつでも分散型の方が高速です。 foozy@708: これは、 foozy@708: 中央集約型では殆どのメタデータが中央サーバ上にしか存在しないため、 foozy@708: 多くの定型処理の度にネットワーク越しにサーバとの通信が必要、 foozy@708: という単純な理由のためです。 foozy@708: 分散型の場合は、全てのメタデータを手元に格納しています。 foozy@708: 他の全てが同じだとしても、 foozy@708: ネットワーク越しの通信は中央集約型にとってのオーバヘッドとなります。 foozy@708: 構成管理ツールとの対話に多くの時間を費やそうと言うのですから、 foozy@708: テキパキと動く応答性の良いツールの価値を軽視してはいけません。 foozy@708: foozy@708: 繰り返しになりますが、 foozy@708: 分散型はメタデータを何箇所にも複製できるので、 foozy@708: サーバ環境の気まぐれ\footnote{訳注: foozy@708: 特定のサーバの動作不良等}は気になりません。 foozy@708: 中央集約型でサーバが火を噴いた場合には、 foozy@708: バックアップメディアの信頼性と、 foozy@708: 最後のバックアップが最近のものであることを祈るに違いありません。 foozy@708: 分散型の場合、 foozy@708: 各開発者のコンピュータ上に無数のバックアップが存在することになります。 foozy@708: foozy@708: 分散型は中央集約型の場合よりも、 foozy@708: ネットワークの信頼性による影響を受けません。 foozy@708: それどころか、 foozy@708: 非常に限定的な幾つかのコマンドを除けば、 foozy@708: 中央集約型ではネットワーク接続抜きには何もできません。 foozy@708: 分散型の場合、 foozy@708: 作業中にネットワーク接続が切れても、 foozy@708: その事に気付かないかもしれません。 foozy@708: 他のコンピュータ上のリポジトリとの連携だけはできなくなりますが、 foozy@708: 手元のリポジトリとの連携と比べれば、 foozy@708: そのような連携が必要な事態はわずかなものです。 foozy@708: 分散しているな共同作業チームの場合には、 foozy@708: これは重要です。 foozy@708: foozy@708: \subsection{Advantages for open source projects} foozy@708: foozy@708: ソースをハッキングしてみようと思ったオープンソースのプロジェクトが、 foozy@708: 分散構成管理ツールを使用していた場合、 foozy@708: 自身をプロジェクトの``中核''とみなす人達と直ちに対等になれます。 foozy@708: 彼らがリポジトリを公開していれば、 foozy@708: 内部の人達と同じツール・同じ手順で、 foozy@708: プロジェクトの履歴のコピーや、変更の実施、作業の記録といったことを、 foozy@708: すぐにでも行うことができます。 foozy@708: 中央集約型の場合はそれとは対照的に、 foozy@708: 中央のサーバに対する変更コミットの権限を与えられない限り、 foozy@708: ``読み込み専用''モードでしか使うことができません。 foozy@708: コミット権限が付与されるまでは変更の記録はできず、 foozy@708: 中央のリポジトリとの同期の際には常に手元での変更が破損する危険を抱えています。 foozy@708: foozy@708: \subsubsection{The forking non-problem} foozy@708: foozy@708: 分散構成管理ツールは、 foozy@708: プロジェクトを``分裂''させ易くしてしまうため、 foozy@708: オープンソースプロジェクトにとってある種の危険要因となる、 foozy@708: と言われてきました。 foozy@708: 分裂は、 foozy@708: これ以上一緒に開発を継続できないと結論付ける原因となるような、 foozy@708: 開発グループ間での意見や特性の相違のがある場合に発生します。 foozy@708: 両陣営は、 foozy@708: プロジェクトのソースコードの概ね完全なコピーを持って、 foozy@708: お互いの方向へと分かれてゆきます。 foozy@708: foozy@708: 時には、分裂した各陣営が、 foozy@708: お互いの相違に折り合いを付ける決定をすることがあります。 foozy@708: 中央集約型の構成管理システムでは、 foozy@708: 折り合いを付けるための\emph{技術的な}処理が苦しく、 foozy@708: 大部分は手動で実施しなければなりません。 foozy@708: 誰の変更履歴が``生き残る''のかを決定した上で、 foozy@708: 何とかして他のチームの変更をソースツリーに移植しなければなりません。 foozy@708: この作業は通常、 foozy@708: 他方の履歴情報の一部ないし全部を失うことになります。 foozy@708: foozy@708: 分散型にとっては、 foozy@708: 分裂こそがプロジェクトを発展させる\emph{唯一の}方法なのです。 foozy@708: 個々の変更は、全て潜在的な分裂点なのです。 foozy@708: 分裂は常に発生している全く基本的な事象なので、 foozy@708: 分散構成管理は実際に分裂を上手く\emph{マージ}できなければならない、 foozy@708: という点にこの考え方の強みがあります。 foozy@708: foozy@708: 全ての人の全ての作業が、 foozy@708: 常に分裂とマージの観点から組み立てられた場合、 foozy@708: オープンソース世界が``分裂''として言及するものは、 foozy@708: \emph{純粋に}社会的な問題となるでしょう。 foozy@708: どちらかといえば、 foozy@708: 分散型は分裂の可能性を\emph{低下}させています。 foozy@708: foozy@708: \begin{itemize} foozy@708: \item 中央集約型が招いてしまう``内部''(コミット権限を持つ人々) foozy@708: と``外部''(持たざる人々)といった社会的区分を無くします。 foozy@708: foozy@708: \item 構成管理ソフトウェアの視点では、単なるマージに過ぎませんので、 foozy@708: 社会的分裂の後の和解を容易にします。 foozy@708: foozy@708: \end{itemize} foozy@708: foozy@708: プロジェクト全般への緊密な統治の維持が中央集約型ツールによって得られる、 foozy@708: と信じているために、分散型に抵抗する人もいます。 foozy@708: しかし、そういった期待の元で foozy@708: CVS ないし Subversion によるリポジトリを公開しても、 foozy@708: 無数に存在するツールによって、 foozy@708: プロジェクト全体の履歴を(例え遅いとは言え)取り出し、 foozy@708: あなたの制御の及ばない場所で再構築することができてしまいます。 foozy@708: ``プロジェクト全般への緊密な統治の維持''が錯覚である一方、 foozy@708: So while your control in this case is illusory, you are foozy@708: foregoing the ability to fluidly collaborate with whatever people feel foozy@708: compelled to mirror and fork your history. foozy@708: XXXXXX foozy@708: foozy@708: \subsection{Advantages for commercial projects} foozy@708: foozy@708: 多くの商業プロジェクトは、 foozy@708: 世界中に散らばったチームが請け負っています。 foozy@708: 中央のサーバから遠く離れたメンバーは、 foozy@708: コマンド実行の遅さや、 foozy@708: おそらく殆ど信頼性の無いサーバとの接続を目にすることでしょう。 foozy@708: 商業的な構成管理システムは、 foozy@708: 遠隔サイト複製\footnote{訳注: foozy@708: ``保守が大変''と言っていることから、 foozy@708: この場合の複製は``サーバの複製''を指しているのかな? foozy@708: }の追加機能によるこれらの問題を解決しようとしていますが、 foozy@708: 通常、こういった機能は高価で保守が大変です。 foozy@708: 分散型の場合は、 foozy@708: そもそもこういった問題で悩む必要がありません。 foozy@708: 更に、例えばサイトごとに一台ずつという塩梅で、 foozy@708: 信頼できるサーバを複数立ち上げることも簡単ですので、 foozy@708: 高価で距離のあるネットワーク経路越しのリポジトリ間で、 foozy@708: 余計な通信をする必要はありません。 foozy@708: foozy@708: 中央集約型の構成管理システムは、 foozy@708: 相対的にスケーラビリティが低い傾向にあります。 foozy@708: 高価な中央集約システムだからといって、 foozy@708: 平行利用する数ダースのユーザの負荷によってダウンしてしまうことは、 foozy@708: 有り得ないことではありません。 foozy@708: 繰り返しになりますが、 foozy@708: 高負荷におけるダウンに対する典型的な対応は、 foozy@708: 高価で古臭い複製機能の利用です。 foozy@708: 分散型ツールを使用する場合、中央サーバ-- foozy@708: 仮に持っているとしても一台だけでしょうが foozy@708: --における負荷は非常に低いので、 foozy@708: もっと大人数のチームの要求を単一の安価なサーバで捌くことができますし、 foozy@708: 負荷分散は単にスクリプト作成の問題となります。 foozy@708: foozy@708: 顧客の元に出て問題対応するメンバーがいる場合、 foozy@708: 分散構成管理は有益です。 foozy@708: 他のビルドからは隔離された状態で特別なビルドのために複数の修正を試したり、 foozy@708: 障害や退行の要因をソースの修正履歴から効果的に検索したりといったことを、 foozy@708: 客先環境で自社のネットワークに接続すること無しに行うことができます。 foozy@708: foozy@708: \section{Why choose Mercurial?} foozy@708: foozy@708: Mercurial は、 foozy@708: とりわけ構成管理システムとして良い選択をしたと言える、 foozy@708: 類を見ない特徴を持っています。 foozy@708: foozy@708: \begin{itemize} foozy@708: \item 習得・利用が容易 foozy@708: \item 軽量 foozy@708: \item 規模拡大に耐え得る foozy@708: \item 改造が容易 foozy@708: \end{itemize} foozy@708: foozy@708: 構成管理システムに慣れ親しんでいるのであれば、 foozy@708: Mercurial を使えるようになるのに5分も掛からない筈です。 foozy@708: そうでない場合でも、 foozy@708: 更に数分以上は掛からないでしょう。 foozy@708: Mercurial のコマンドや機能群は、 foozy@708: 全体的に統一性と一貫性が保たれていますので、 foozy@708: 沢山の例外事項ではなく、 foozy@708: 少数の一般的な方法だけを覚えておけば良いのです。 foozy@708: foozy@708: 小さなプロジェクトの場合、 foozy@708: すぐにでも Mercurial を使い始めることができるでしょう。 foozy@708: 新たな変更やブランチを生成し、 foozy@708: 変更を(同一ホストないしネットワーク越しで)持ち歩いたり、 foozy@708: 履歴参照や状態確認といった全ての操作が高速です。 foozy@708: 元来非常に高速な操作に加えて、 foozy@708: 目に見えるオーバーヘッドが少ないために、 foozy@708: Mercurial は俊敏さを保ち、 foozy@708: 利用者の作業を妨げることを避けることができます。 foozy@708: foozy@708: Mercurial の有用性は小さなプロジェクトに限定されません。 foozy@708: 数百から数千のメンバを持ち、 foozy@708: ソースコードが数万ファイル・ foozy@708: 数百メガバイトに及ぶプロジェクトでも採用されています。 foozy@708: foozy@708: Mercurial の基本機能に満足できない場合でも、 foozy@708: 容易に拡張することができます。 foozy@708: Mercurial は処理のスクリプト化に適しており、 foozy@708: Python を使って綺麗に実装されていることが、 foozy@708: 「イクステンション」という形式での機能追加を容易にしています。 foozy@708: 「障害特定の補助」から「性能向上」といった広い範囲で、 foozy@708: 評判の良い有用な多くのイクステンションが既に提供されています。 foozy@708: foozy@708: \section{Mercurial compared with other tools} foozy@708: foozy@708: この先を読む前に、 foozy@708: 著者自身の経験/関心/(あえて言いますが)偏見といったものが、 foozy@708: 本節に反映せざるを得ない点をご理解ください。 foozy@708: 著者は、以下にあげる構成管理ツールのそれぞれを、 foozy@708: 最長で数年程度使用した経験があります。 foozy@708: foozy@708: \subsection{Subversion} foozy@708: foozy@708: Subversion は CVS の置き換えを目指して開発された、 foozy@708: 評判のよい構成管理ツールです。 foozy@708: Subversion は中央集約型の「クライアント/サーバ」 foozy@708: アーキテクチャを持っています。 foozy@708: foozy@708: Subversion と Mercurial は、 foozy@708: 同じ作用を持つ似たような名前のコマンドを持っているので、 foozy@708: 一方に馴染みのあるユーザは他方の用法を容易に習得できます。 foozy@708: これらは両方とも全ての著名な OS 上で利用可能です。 foozy@708: foozy@708: Subversion は履歴を意識したマージ機能を持っていないので、 foozy@708: どのリビジョンのブランチ間でマージすべきかを、 foozy@708: ユーザ自身が厳密に指定することを強制します。 foozy@708: この指定ができなかったり間違えたりした場合、 foozy@708: マージにおける不必要な衝突を手動で解決する羽目になります。 foozy@708: foozy@708: 著者がベンチマーク計測した限りでは、 foozy@708: Subversion の全ての構成管理操作において、 foozy@708: Mercurial は性能の面で相当に優位にいます。 foozy@708: 筆者の比較によると、 foozy@708: Subversion の 1.4.3~版における foozy@708: \emph{ra\_local} ファイル格納 foozy@708: (利用可能な最速のアクセス機能)と比較した場合、 foozy@708: 2倍から6倍程度の優位性がありました。 foozy@708: ネットワーク越しのリポジトリを必要とする、 foozy@708: より現実的な配置の場合、 foozy@708: Subversion は相当に不利な状況になるでしょう。 foozy@708: 多くの Subversion コマンドはサーバとの連携が必要な上に、 foozy@708: Subversion は有用な複製機能を持っていないため、 foozy@708: 少々大きめのプロジェクトの場合、 foozy@708: サーバの性能がボトルネックとなるでしょう。 foozy@708: foozy@708: それに加えて、 foozy@708: ファイルの更新の検索(\texttt{status}) foozy@708: や現行版との差分表示(\texttt{diff})といった、 foozy@708: 幾つかの共通操作におけるネットワーク処理を回避するために、 foozy@708: Subversion は相当な格納オーバヘッドを抱え込んでいます。 foozy@708: Mercurial のリポジトリがプロジェクトの完全な履歴を保持しているにも関わらず、 foozy@708: Subversion が抱え込む作業コピーは、 foozy@708: Mercurial リポジトリと作業領域ディレクトリのサイズと、 foozy@708: 結果としておおよそ同サイズか、あるいはそれ以上になることが多いです。 foozy@708: foozy@708: 構成管理関連のサードパーティツールに関しては、 foozy@708: その差は徐々に埋まってはいるもの、 foozy@708: Mercurial と比較して、 foozy@708: 現時点では Subversion の方がより多くのサポートを受けることができます。 foozy@708: また、Mercurial と同様に foozy@708: Subversion は素晴らしいユーザマニュアルがあります。 foozy@708: foozy@708: Subversion リポジトリから Mercurial リポジトリへの、 foozy@708: 正確で完全な変更履歴の取り込みを行うツールが幾つもありますので、 foozy@708: 古いツールからの移行は比較的容易です。 foozy@708: foozy@708: \subsection{Git} foozy@708: foozy@708: git は、 foozy@708: Linux カーネルソースツリーを管理するために開発された分散構成管理ツールです。 foozy@708: Mercurial と同様に、 foozy@708: その初期の設計は Monotone から影響を受けています。 foozy@708: foozy@708: git は圧倒的なまでのコマンド群を持っており、 foozy@708: 1.5.0~版においては 139~個の独立したコマンドがあります。 foozy@708: これらは習得が難しいとの評判です。 foozy@708: ユーザマニュアルが存在せず、 foozy@708: 個別のコマンドに関する文書があるのみです。 foozy@708: foozy@708: 性能の面では git は非常に高速です。 foozy@708: 少なくとも Linux においては、 foozy@708: Mercurial よりも git の方が早いケースが幾つかあります。 foozy@708: しかしながら本書の執筆時点では、 foozy@708: Windows 環境における性能(および一般的なサポート)に関しては foozy@708: Mercurial に及びません。 foozy@708: foozy@708: Mercurial のリポジトリは保守の必要がありませんが、 foozy@708: git リポジトリは手動によるメタデータの``詰め直し''を頻繁に行う必要があります。 foozy@708: この詰め直しをしない場合、 foozy@708: 利用領域が速やかに増加する一方で、性能が低下してしまいます。 foozy@708: 厳格且つ頻繁に詰め直しをしない git リポジトリを沢山抱えるサーバは、 foozy@708: バックアップの間、非常に disk-bound になりますし、 foozy@708: 結果として、 foozy@708: 日時バックアップ処理に24時間以上を要するようになってしまった例が、 foozy@708: いくつもあります。 foozy@708: 詰め替えによって鮮度が保たれている git リポジトリは、 foozy@708: Mercurial のリポジトリよりもわずかに小さいですが、 foozy@708: 詰め替えされていない場合はかなりの大きさです。 foozy@708: foozy@708: git の基本部分は C で実装されています。 foozy@708: 多くの git コマンドはシェルないし Perl のスクリプトにより実装されていますが、 foozy@708: その品質は非常に幅が広いです。 foozy@708: 致命的とみなすべきエラーが発生している中で闇雲に処理を続けるスクリプトを、 foozy@708: 何度か見かけたことがあります。 foozy@708: foozy@708: \subsection{CVS} foozy@708: foozy@708: CVS はおそらく世界中で最も広く使用されている構成管理ツールです。 foozy@708: その歴史の長さと、内部的なまとまりの無さから、 foozy@708: 長い間、本質的には保守されてきませんでした。 foozy@708: foozy@708: CVS は中央集約型の「クライアント/サーバ」 foozy@708: アーキテクチャを持っています。 foozy@708: CVS は関連するファイルの変更を不可分コミットへとグループ化しないため、 foozy@708: 例えば、 foozy@708: 「ある利用者による成果のコミットが、 foozy@708: マージの必要性から部分的にしか成功しなかった場合、 foozy@708: 他の利用者からは彼の意図した変更の一部しか見ることができない」といった、 foozy@708: ``ビルドを乱す''行為が容易に行えてしまいます。 foozy@708: これは、プロジェクト履歴に対する作業の進め方にも影響します。 foozy@708: とあるタスクの一部として、 foozy@708: あるメンバが行った変更を全て表示しようとした場合、 foozy@708: 関連する各ファイル(どのファイルがそうであるかを知っていれば、 foozy@708: の話ですが)に対して行われた変更の、 foozy@708: 個々のコミットログと日付を手動で確認する必要があります。 foozy@708: foozy@708: CVS のタグやブランチの考え方は混乱しているため、 foozy@708: それについて説明する気にもなれません。 foozy@708: ファイルやディレクトリの改名がサポートされていないため、 foozy@708: リポジトリが簡単に雑然としてしまいます。 foozy@708: 内部的な整合性をチェックする機能も持たないため、 foozy@708: リポジトリが破損しているのか否かを判定したり、 foozy@708: どのように破損しているのかをしることは、一般には不可能です。 foozy@708: 現存・新規のいずれのプロジェクトに対しても、 foozy@708: CVS はお薦めできません。 foozy@708: foozy@708: Mercurial は CVS のリポジトリを取り込むことができます。 foozy@708: しかし、いくつかの注意が必要で、 foozy@708: これは CVS のリポジトリを取り込むことのできる、 foozy@708: 他の構成管理ツールに対しても同様です。 foozy@708: CVS は不可分コミットを持っておらず、 foozy@708: ファイルシステム階層の履歴管理も行っていないため、 foozy@708: CVS から履歴を正確且つ厳密に再構築することは不可能です。 foozy@708: 幾分かの推測が必要であり、改名は通常検知できません。 foozy@708: 高度な CVS 管理の多くが手動で行われ、それ故に間違いやすいことから、 foozy@708: CVS からの取り込みを行うツールにとって、 foozy@708: 破損したリポジトリからの取り込みは複数の問題に行き当たるのが常です foozy@708: (筆者の個人的経験から思い出せる、面白くも無い問題の例としては、 foozy@708: 完全に偽物のタイムスタンプや、 foozy@708: 10年以上ロックされたままのファイルなどがあります)。 foozy@708: foozy@708: \subsection{Commercial tools} foozy@708: foozy@708: Perforce は中央集約型の「クライアント/サーバ」 foozy@708: アーキテクチャを持っていますが、 foozy@708: クライアント側では全くキャッシュを行っていません。 foozy@708: 近年の構成管理ツールと異なり、 foozy@708: 編集対象となる全てのファイルに関して、 foozy@708: Perforce はコマンド実行によるサーバへの通知をユーザに対して要求します。 foozy@708: foozy@708: Perforce の性能は小規模なチームでは非常に良好ですが、 foozy@708: ユーザ数が数ダースを超える頃から急速に低下します。 foozy@708: 少々大規模な開発向けの Perforce インストールは、 foozy@708: ユーザアクセスによる負荷を上手く処理するために、 foozy@708: 「プロキシ」の配置が要求されます。 foozy@708: foozy@708: %%% Local Variables: foozy@708: %%% mode: latex foozy@708: %%% TeX-master: "00book" foozy@708: %%% End: