Notes from the version control BOF at the summit

[Ian Lance Taylor <ian at wasabisystems dot com>]

昨日バージョン管理システムに興味のある人々の間での会議を開きました。
見聞きしたことのメモを送ることを約束していましたが、これがそうです。
ここにある意見は私個人のものであり、何かの集団の合意によるものでは
ありません。私が書き下した考えだけがあります; 他のことについては
失念しているかも知れません。個人的にはこの問題について強い意見を
もっていませんし、せいぜい報告書のたぐいと考えてください。議論では
ありません。

gcc は egcs プロジェクトが 1997 年に始まってから CVS を利用してずっと
開発が進められてきました。(その前は RCS を使っていました。)　CVS で
gcc の開発を支援することが可能であるのは明らかですが、いくつかのよく
知られた問題があり、いくつかを以下で取り上げようと思います。

今日ではさまざまな他のバージョン管理システムが利用可能です。このなか
には cvsnt, subversion, monotone, arch そして darcs があります。
(Bitkeeper は問題外です。フリーソフトウェアではありませんから。) 
別のバージョン管理システムに移行することを考えるのは私たちにとって
意味のあることです。
このようなわけで、今回の集まりでは、gcc 用のバージョン管理システム
には何が求められるかを議論しました。また Graydon Hoare 、これは
monotone の作者ですが、バージョン管理システム開発について語り、
それについての意見を求めました。

gcc がバージョン管理システムに求めることはある程度はっきりしています:
CVS によって日々利用している機能が使えなくてはなりません。CVS のすべて
の機能が必要なわけではありません--たとえばラッパーのたぐいは不要です
-- が、大部分は必要です。gcc が本当に恩恵をうけるかどうか少し不明な
ところもありますが、会議にいる人々によって提案された要求機能は以下
のようなものです。

* 現在までの履歴を保存できなければならない
　　既存の CVS 履歴情報を捨てることはできません。より古い RCS 情報を
　　失うこともできません(それは gcc.gnu.org の CVS リポジトリにある
　　old-gcc ディレクトリから取得できますが、それでは不便です)。

* CVS へのエクスポートが可能でなければならない
　　使ってみて、やはりダメだったという場合にそなえて。

* システムはある程度の間存続し、サポートされるものでなければならない
　　少なくともしばらくの間利用したいのであって、システムを何度も変更
　　することは望みません。

* 単一の主系(single blessed version)管理をサポートしていなければならない
　　CVS はこれ以外の方法で動作することはできませんが、分散システムでも
　　このモードが必要です; 詳しくは以下を見てください。

* 不分割なチェンジセット
　　一つの単位としての完全なチェックインを参照する能力がなければなり
　　ません。CVS はこれをサポートしていません: 同時に複数のファイルを
　　チェックインすると、CVS はそれぞれのファイルに対する独立のチェックイン
　　がおきたかのように振舞います。

* ファイル名変更の追跡
　　CVS はファイル名称変更に対応していません。ファイルの名称変更や
　　追加によってリビジョン履歴が失われてしまいます。

* ブランチ作成のためのコストが低いこと
　　CVS ではブランチを作るのは時間のかかる処理です

* タグ作成のコストが低いこと
　　やはり CVS ではタグを作るのは時間のかかる処理です

* 最後のマージ地点を記憶しておけること
　　ブランチ間でマージする場合自動的にブランチがマージされた場所を記憶
　　し、追加マージが簡単にできるようになっていなければなりません。

* リポジトリの複製
　　リポジトリのコピーを簡単に作れると便利です。

* オフラインでの作業能力
　　例えば、インターネットに接続されていない状態で diff をとったり
　　ログの内容を参照できなければなりません。システムによっては非接続時
　　のコミットすら可能なものもあります; 詳しくは以下を見てください。

* どのブランチにある特定のパッチが適用されたかを知る能力
　　ある変更が特定のブランチ上に適用されたかどうか、逆にどのブランチに
　　ある変更が適用されていないかを知ることができると便利です。

* 特定のブランチにパッチセットをコピーできること
　　パッチセットを出力する仕組み。パッチセットは一つ以上の変更のまとまり
　　であり、このまとまりを特定のブランチ上に適用できるような能力。
　　もちろんこれは衝突をおこすこともあるでしょうが、diff/patch のような
　　ものよりもすぐれた仕組みがあれば便利でしょう。

* Unix, Windows, Mac、どのプラットフォームでも動作すること
　　CVS はすでにそうですが、これが私たちには必要です。

* 言語のサポートと文字コード変換
　　簡単な例でいえば、テキストファイルの改行の問題などがあります。

* テキストとバイナリの両形式のサポート
　　やはりテキストファイルとバイナリファイルが正しく扱えなければ
　　なりません。CVS はすでに可能です。

* バージョン履歴上でのテキスト検索
　　特定のシンボルを変更したパッチがどれか、などの条件で検索できる
　　能力。

* ある特定の行を誰が削除したかを知ること
　　'cvs annotate' で誰がその行を追加したかを知ることはできますが
　　誰がある行を削除したかを知るのは困難です。

* リポジトリを高信頼性のもとでバックアップできること
　　CVS では簡単ではありません。私たちのバックアップシステムは
　　CVS ロックにうまく対応していないのでコミット途上のバックアップ
　　をとってしまう可能性があります。

* 完全な Cygnus/Red Hat 開発リポジトリを扱うことのできるような幅
　広いスケーラビリティー

　　これが私たちの知りうる最大の単一リポジトリであり、さまざまな
　　プロジェクトが 1991 年程度までさかのぼることのできる CVS
　　リポジトリです。

* 最新の正しい状態がどれであるかを簡単に知ることができる
　　特定のターゲット用に動作することがわかっている最新の状態で
　　作業ディレクトリを簡単に更新することができる機能

* bugzilla と gcc-patches に統合できること
　　CVS は現在 bugzilla に統合されています--適切な印がコミット
　　メッセージ中に置かれると、PR(問題報告)にそのコミットメッセージが
    追加されます。gcc-patches との
　　統合も便利です。ログエントリからの自動的なリンクが、パッチの内容を
　　示すアーカイブされた e-mail メッセージに向けられます。 

* 同じバージョン管理システムを使って別のプロジェクトとの間でクロスマージ
　できること

　　libgcj などでは Classpath (あるいは同様のもの)との間でマージしたり
　　戻したりできると便利です。

* 管理者用の、パッチを許可するための単一操作
　　投稿者にコミットするように指示するかわりに、パッチをコミットするための
　　ワンタッチ操作が保守者に用意されていると便利です。

* 簡単なパッチの取り消し
　　一度適用したパッチを取り消す仕組みがあると便利です。現時点では
　　パッチを明示的に逆向きに適用することでやっています。


大まかに言って、バージョン管理システムは集中型と分散型に大きく
分けることができます。CVS は集中型です。monotone や arch のような
分散型システムでは誰でもリポジトリの完全なコピーを持つことができます。
一見これはバカな要求のように見えますが、今日のハードディスクの価格の
低下を考えると現実的なものになってきています。たとえば gcc の完全な
リポジトリは 2 ギガバイト程度の領域が必要になります。

分散型システムは多くの操作を早く実行できます。オフラインで作業できます
し、コミットすらそうです。

オフラインコミットはコミットの時系列化の問題を起こします。私たちは
一つの公式な主系ラインを必要としています。つまり、単一ファイルに対する
同時におこるコミットを効率を問題にしなくてはならないということです。
CVS はサーバに対する要求を強制的に時系列化することによって同時コミット
を防いでいます-- 二番目のコミットは "最新状態チェックエラー"
で拒否されます。オフラインコミットではこれは選択肢とはなりません。
(分散型システムでさえ、おそらく外部プログラムを通じて、再びオンライン
となった時の強制的な時系列化を実行することができるでしょう)。

この問題の別の設定の仕方は、こうです。効率的に同時コミットをやるには
誰がマージするのか? CVS の場合コミットする人がマージします。gcc の観点
から言うとこれは問題の分散的な解決となりますが、その問題を最も深刻に
受け止めている人にその問題の判断を戻すという形になります。

オフラインコミットの場合、マスタリポジトリは複数の意味のあるコミット
を同時に受け取る可能性があります。これらコミットは時系列化されていなくては
ならない、あるいは別の方法としては、マージされなくてはなりません。
どうやったら良いのでしょう?


[ 以下の内容に間違いがあるようなら謝ります ]


monotone ではブランチごとに複数のヘッドを持つことができます。マージ操作
は複数のヘッド間で 3 ウェイマージを実行することでおこないます。
これは衝突を起こすかも知れないので解消されなくてはなりませんが、
多かれ少なかれ CVS が現在やっているような感じになります。
monotone は特定のリビジョンにサインすることができます。gcc の公式バージョン
は適切なキー、あるいは複数のキーによって１番最近にサインされたブランチ上にある
ことになります。言い換えると管理者はマージをしますが、これは部分的に自動化
されているということです。

arch の場合それぞれのリポジトリ自身が変更の時系列点となります。
変更はあるリポジトリから別のものに強制的に送られることはなく、
自分で取り込む必要があります。このためマスターリポジトリ上のある人(あるいは
ある自動化されたプロセス)が他のリポジトリからのリビジョンの取り込みに関して
責任を持つ必要が出てくるかも知れません。ここではマスターリポジトリ上でプロセスを
実行することによってコミッターがマージをします。

darcs は多かれ少なかれ arch に似たものだと思います。

言い換えると arch あるいは darcs ではマスターリポジトリ上にコミットされた
変更点を明示的に反映させる必要があります。monotone ではマスタリポジトリ
の同期操作が必要になります; 同期処理は自動的にあなたのコミットを転送しますが、
そのことによって、このコミットがただちに公式なものとはなるわけではありません。

時系列に関する主な問題は、もちろん ChangeLog ファイルになります。これらのシステム
のほとんどでは ChangeLog ファイルの自動的なマージを書き込むことができますが
それは正しい設計でしょう。

これで私の話は全部ですが、どうすれば良いかについては、私はなんの意見も持って
いません。ただ他の人の意見を聞きたいとは思っています。このような話題はすぐに
フレーム(メーリングリスト上でのデスマッチのこと-tez)に成り下がってしまうので
CVS にとどまる、あるいは別の特定のシステムに移行する(あるいはそれに移行しない)
という議論をする際には、かならず具体的な理由をつけるようにしてください。

Ian



翻訳: 上平　哲<tez@kamihira.com>