Home » Tags » BOSBook
Mercurial: "Managing change with Mercurial Queues" を読む(1)
Submitted by fujiwara on 2007, July 23 - 7:44pm.
Tagged:  •    •  

私が、関与するプロジェクトのソフトウェア構成管理(SCM)を片っ端から Mercurial 化していることもあり、 弊社は比較的「Mercurial 度」が高いと思われますが、 利用ユーザ数の点でメジャーな CVS や Subversion に比べて日本語による情報が圧倒的に少ないため、 現時点では Mercurial の導入／利用は障壁が高いのも確かです。

一応、チュートリアルをはじめとする幾つかのページが既に日本語化されていますが、 網羅性や詳細度の点で今ひとつの感が拭えません。

とりあえず「自分の出来る範囲からの貢献」ということで、 暫く前に公開された "Distributed revision control with Mercurial" の翻訳を始めてみました。

ここでは、 翻訳過程における考察／感想等を翻訳作業と平行して書いてみようと思います。 読み込みや理解の不足に基づく誤記等に関しては、 ご容赦ならびにご指摘頂ければ幸いです。

ちなみに、翻訳の途中経過を公開しても良いのですが、 (1) 結構な分量があることと、 (2) なにぶん元ドキュメントが *.tex 形式ということもあり、 ある程度まとまってから原著者経由で公開してもらおうと考えております。 興味のある方は ascade.co.jp の fujiwara 宛てにご連絡ください。

折角「翻訳」という「深読み」をするのですから、 自分が一番理解していない事について書いてあるところから始めよう、ということで、 "Managing change with Mercurial Queues" から始めてみました。

12.1 The patch management problem

この節では、 オープンソースソフトなどのように、 「自分が改変権限を持たない上流(upstream)リポジトリ」 で管理される成果物に対して:

  1. 自分の改変内容を保持しておく
  2. 上流リポジトリの更新を反映する
  3. 自分の改変のうち、必要なものを再度適用する

といったことを手動で行うのは大変だ、 という事例を、 「パッチ管理問題」の典型として説明しています。

「改変権限」と「開発への参加」が切り離されている OSS と、 両者がほぼ等価である社内プロジェクトのような状況下の開発（以下「閉じた開発」）では、 この辺の事情は全く異なってくるでしょう。

全ての変更を直接リポジトリに反映できるのであれば、 そもそも「パッチ管理問題」自体が存在しません （別途「ベースライン管理」の問題が浮上してきますが…）。 事実、 弊社のプロジェクトでは Mercurial Queues（以下 MQ）は使用せずに、 通常のチェンジセットのみでの管理を行っていますが、 それでも十分に開発の効率化が図れています。

12.2 The prehistory of Mercurial Queues

この節では、 MQ の説明に先立って、 Linux 開発におけるパッチ管理の歴史について説明しています。

quilt と呼ばれるパッチ管理ツールが公開されたのが 2003 年初頭、 と随分最近（でもないですか？）の話なのも意外ですが、 Linux カーネルソースに公式な構成管理ツールが導入されたのが2.5 ～ 2.6 版開発の頃から、 という驚きに比べればそれほどでもないでしょう。

ちなみに、Linux カーネルソース管理への SCM ツールの導入それ自体は喜ばしいことなのでしょうが、 最初に導入された SCM ツールである BitKeeper のライセンス問題のゴタゴタにより、 "Distributed revision control with Mercurial" の原著者である Bryan O’Sullivan 氏が Mercurial 開発への参画を断念せざるを得ない事態に繋がるなど、 手放しでは喜べない側面も…。

12.3 The huge advantage of MQ

この節では、 （従来の）構成管理ツールは「永続的な記録が残ってしまうのが堅苦しい」と、 構成管理の利点をいきなりひっくり返す記述があります。

「それを言っては身も蓋も無い」気がしますが、 「上流リポジトリ」が自身の制御の及ばない状況の場合、 Mercurial のようにローカルリポジトリへの自由な commit が出来るからといって、 「永続的な記録」＝チェンジセットを残してしまうと、 その後の「上流リポジトリ」の更新への追従の際には継続的な merge が必要とされます。 そのようなことから「永続的な記録が残ってしまうのが堅苦しい」 と思ってしまう気持ちはわからないでもありません。

この辺は、 制御できない外部要因とのすりあわせが常に要求される OSS （に関わる）開発と、 開発プロセスや品質管理／開発分担といったものが制御しやすい閉じた開発とで、 意識が全然違ってくるところでしょう。

12.4 Understanding patches

この節では、Mercurial がパッチに用いている unified diff 形式に関する概要を説明しています。

CVS は context diff 形式を用いていますが、 昨今のパッチ形式はどれが主流なんでしょうか？ 以前「unified diff 形式が他よりも優れている」 云々という記述を見かけた気がするのですが…。


以下、次回に続く。


"Distributed revision control with Mercurial" 関連エントリの一覧は、BOSBook(Bryan O’Sullivan Book)タグで参照できます。