ものすごい駆け足で説明してきたが、こういうアイディアは昨日の 今日で一人の人間の頭の中だけで思いつくものではない。私の知る限り、 おそらく 20〜30年くらいの歴史の中で少しずつ少しずつさまざまな議論 を通じて育ってきたものだ。そして今から数年前に、一応の完成をみた。 このシステムをコンカレントバージョンシステム、CVS と言う。CVS は今 言ったような形式で、複数のファイルをひとつにまとめたディレクトリ、 あるいはツリーを管理することができる。CVS の細部は、とてもここで語 り尽くせるものではないが、今までの議論で触れていないひとつの大きな 特徴がある。それは、分岐、という概念だ。GNU arch が作られた最も大 きな理由の一つは、CVS の持つ、この分岐概念の不完全さからくるので、 以下の節では分岐、そしてこれをペアになる「マージ」ということについ て詳しく説明しようと思う。分岐とマージは、今までの例のように一人で データを管理しているときには表に現れない。しかし複数の人間が協調し て一つのデータを管理する場合には本質的なものとして現れるのだ。
さて、ここで CVS について最低限の説明をしようと思う。前の節 で言ったように、生の GNUdiff と GNUpatch を使いやすくまとめて誰で も使えるようにしたパッケージを作ろうという動きは非常に早くからあっ たようだ。CVS はこの流れの中で数年前に一応の完成を見た。実はこのド キュメントを書くに当たって、CVS が完成に至る過程を詳しく追いたかっ たのだが、ネット上を検索してもなかなか良い文献には出会えなかった。 唯一参照できそうだったのが CVS に関連したメーリングリストの情報で、 いくつかのリストについては 1993/2 くらいまで遡れるものもあるような のだがアーカイブ全体をテキストファイルに落すことができず、結局詳し く追体験するには至っていない。私はこれらの歴史に非常に興味があるの で、バージョン管理システムの過去について詳しい方や、CVS 関連の非常 に古いメーリングリストのアーカイブなどを保存されておられる方がいた ら是非私に御連絡頂きたいと思う。いずれにせよ、CVS は昨日の今日でで きたようなシロモノでないことだけは確かだ。私の知る限り、20〜30年く らいの歴史の中で、多くの人々の議論の中で徐々に形をとっていたものだ と考えられる。この物語の中には「一人の天才」のようなドラマはないこ とだけは確かだ。人間一人では何にもできない。
ここでは CVS の膨大な機能の中で、基本となる部分と、GNU arch との関連で重要な「分岐」という応用機能についてしぼって説明しようと 思う。
CVS では二人の登場人物がいる。一つは、「リポジトリ」と呼ばれ るデータ格納庫。もう一つはこの「リポジトリ」にデータを追加するのに 必要な補助的な領域である「作業コピー」だ。「リポジトリ」というとな んだか高尚なもののようだが、実はもう我々はどんなものかイメージする ことができる。そう、前の節で図に書いたような、最初のリビジョンと追 加の差分情報が蓄積されたファイルを集めたディレクトリのことだ。この ディレクトリには、ディレクトリ内にあるすべてのファイルの、全ての履 歴情報が入っている。リポジトリからは、任意のリビジョンのデータを取 り出すことができるし、最新のリビジョンに次の差分を追加して、新しい リビジョンを作ることもできる。リポジトリはとても重要な場所なので、 直接編集したりすることは許していない。かならす CVS システムに対し てこれこれのことをしてくれ、と頼まなくてはならない。これはちょっと 窮屈に思えるかも知れないが、CVS にできる操作しか許さないことで、リ ポジトリのファイルを間違って削除してしまったり、勝手に名前を変えて しまったりといった操作ミスをなくすことができる。閉架式の図書館みた いなものを想像してもらってもいい。本を読みたいと思ったら直接本棚に 行くのではなく、係の人にとってきてもらう。あれと一緒だ。もちろん CVS はなにか神秘的なことをやるわけじゃない。内部的に前の節で話した GNUdiff や GNUpatch を使って一所懸命必要なリビジョンを計算して、君 のためにとってきてくれるというわけだ。あまり詳しくない人から見ると、 リポジトリはものすごい数のリビジョンデータ全体がある巨大な格納庫に 見える。しかし実際には最初のリビジョン以外は差分の集合体なのだった。
もう一つの重要な登場人物が作業コピーと呼ばれる場所だ。CVS か らデータを取り出そうとすると、作業コピーが作られてそこにデータがコ ピーされる。ただコピーされるわけじゃなくて、どのリポジトリから取り 出したか、とか、取り出したリビジョンはどれか、などの情報も記憶して いる。作業コピーは同時に何人でも作ることができる。CVS が呼び出され るたび、呼び出した人用の作業コピーができる。これは閉架式の図書館と は違うところだ。現実の本と違って、デジタルデータはいつでもコピーす ることができるのだ。このコピーを作るための命令を checkout と呼ぶ。 CVS の基本コマンド、その1だ。
CVS での基本的なワークフローはいたって単純だ。まず、リポジト リから最新のリビジョンを作業コピーに checkout 命令で取得する。それ から作業コピーに対して必要な修正を加える。これでいいなということに なったら、CVS システムに対して、今回の作業コピーの内容をリポジトリ に追加してくださいという命令を送る。すると CVS は現在の最新リビジョ ンと作業コピーとの間の差分をとる。それからできた差分をリポジトリを 構成する各ファイルに追加する。この操作を commit と言う。基本コマン ドその2だ。なんだか CVS はエラク高尚なことをしているように思うかも 知れないが、実際には前節で紹介した GNUpatch とか GNUdiff のような プログラムがやるのと同じようなことをしているだけだ。get して、コミッ トする。この繰り返しによって、リポジトリのリビジョンはどんどん増え ていく。
他にも CVS はいろいろなことができる。たとえば、最新リビジョ ンよりも前のリビジョンを取り出すこともできるし、あるリビジョンと別 のリビジョンの差分を計算して、表示させることもできる。既に少し説明 した、ログメッセージの内容を表示させることもできる。これを見れば、 ああ、あの時のコミットは、こんなことをやったのだった、と見当がつく。
話がこれで終ってしまうのなら、CVS は GNUpatch と GNUdiff の やったことを一手に引き受けてくれているだけで、あまりありがたみがな い。CVS が便利なところは、複数の人間がそれぞれ作業コピーを作って同 じリポジトリにコミットできるような仕組みを提供しているところだ。 CVS の C はコンカレントの C だが、それはこのことを意味している。 ちょっと考えればわかるように複数の人間が勝手に checkout して修正を コミットすれば、修正がお互いに衝突してしまったり、相手のした修正点 に気づかず上書きしてしまったりするのは想像がつくだろう。詳しい説明 は省略するが、CVS はこの当たりの交通整理もしてくれる。ある人が修正 した部分に別の人が更に修正しようとすると警告してくれたり、まずは他 の人がした修正点がどんなものであったかを自分の作業コピーに受け取る ように指示してくれたりする。