[目次へ][1章へ][1.1へ][1.3へ]
最終更新：$Date: 2002/09/12 01:25:32 $
■■ [1.2] 何の役に立つの？
■■■ [1.2.1] CVSのできること
■■■ [1.2.2] CVSのできないこと
■■■ [1.2.3] それで結局なんの役に立つのか ※項に分けるほどのことも…
CVSの機能や歴史を説明されても、具体的に何ができるのか、あるいはできないのかといったことはピンとこないと思います。ですので、ここでは著者の思いつく範囲で、できることできないことの説明を試みたいと思います。他にもあるぜ〜と思われる方はぜひ著者に教えてください（マジデ）。
バージョン管理機構を何につかうか、ということです。
■■■■プログラムの開発・利用に使おう！
元が、プログラム開発のためのツールなので、当然プログラム開発には、すばらしく役に立ちます。特に、オープンソースの世界では無くてはならないツールとなっており、オープンソースソフトウェアの開発に参加・協力したり、参加・協力しないまでも最新のソースコードを利用したいだけという場合にも利用でき、たいへん便利です。たとえ、最新のソースコードを利用するというだけでも、「人柱として参加・協力している」ことになるので、ぜひ利用してください。
例えば、Linuxカーネル、FreeBSD、Apache、Mozillaなどの巨大プロジェクトは独自のCVSリポジトリを持ち運営しています。小さなオープンソースプロジェクトのために提供されているSourceForgeなどのサイトでもCVSが利用されています。SourceForgeは最近日本語サイトができたので、著者もちょっと使ってみたりしました。
▼SourceForgeの日本語サイト
[http://sourceforge.jp/]
もちろん、企業でのバージョン管理にも使用できると思います。特にソースコード共有と遠隔からのアクセスに向いています。
■■■■テキストファイルの管理に使おう！
その他に、テキストファイルの管理一般に利用することはできるでしょう。例えば、Webページなどです。差分を取るプログラムdiffが元々テキストファイルを対象としていたので、画像などのバイナリファイルの扱いにはあまり向いていませんが、リポジトリに登録することはできます。CVSを日々のバックアップとして運用する分には問題ないでしょう。
■■■■大事なデータのバックアップに使おう！
CVSを日々のバックアップとして利用する場合、特に次のような場合に役に立つと思われます。移動が多く、移動先で仕事をする人や、家と会社に作業環境がある人など、いくつかのコンピュータで同じファイルを編集する必要がある場合、つまり、一人で複数環境を持つ人は、自分でおこなった並列作業の管理をCVSですると楽になるでしょう。最近の著者はめっきりこのためだけにCVSを使用しています。書類仕事が多くて、移動も多いんですよね…。
無論、複数の人が関わる作業でその真価を発揮することは言うまでもありません。例えば、この原稿の編集さんとのやりとりとか（うっ）。
できないとこも書いておきましょう。CVSの付属マニュアルで挙げられている項目について、筆者なりに説明してみます。
■■■■CVSは構築システムではありません
主にプログラミングでの話なのですが、複数のファイルからなるプログラムの場合、コンパイルをして1つのプログラムに組み上げる「構築（ビルド）」という作業が必要になります。CVSはこの構築作業を助けてくれたりはしません。構築作業を助けてくれるツールとしてはmakeというプログラムが有名です。これもGNUのフリーウェアにありますので、興味があれば触られてみるとよいでしょう。なお、makeの文献としては、本書の姉妹書となる『入門Make&RCS』を挙げておきます。
一般的に、プログラムの中のソースコードファイルは別のファイルに依存しています。この依存関係の端からコンパイルをおこなって、マシン語に変換し、最終的に1つのプログラムに組み上げるのです。あるファイルが変更された場合、全てのファイルをコンパイルするのではなく、変更されたファイルとそれを組み込む部分のみをコンパイルする方法が取られます。そのために必要な作業をCVSがすることはありません。このようなときに、makeを使います。makeは、「依存関係」と、「依存関係に沿ってプログラムを構築するために何をすればよいか」を記述したMakefileというファイルを参照しながら動作します。
このMakefileはプログラマがえっちらおっちら書かないといけないのですが、依存関係についてはまた別のツールを用いて生成することもできます。例えば、Cのプログラムだと、makedependというプログラムが、includeしているファイルを調査し、開発者に教えてくれます。
このようなMakefileがいろいろなディレクトリに作られ、それらが相互に関連した状態にあると、何をするにもプログラム全体を取り出さなければなりません。シェルスクリプトなどを利用する場合も同じです。ディレクトリの独立性を高めて、一部だけ取り出すようにすることも可能ですが、何にしろそんな風に作り込んだりそれを維持するのは結構大変です。CVSはやはりそのへんには全く無関係です。ただ、そうしたMakefileやスクリプトを作った場合にはソースコードと一緒に管理しておくと楽です。
CVSと連係して構築をおこなうための情報は、付属マニュアルの「Builds(構築システムとCVSの関係方法)」という章に書かれています。必要な方はそちらを参照してください。付属マニュアルの見方については第3章で紹介します。
■■■■CVSは管理者の代わりはしません
プログラム開発では通常、管理者がいて、プログラムの期日や何をいつおこなうかをプログラマと相談しながら開発を進めていきます。管理者のそうした仕事をCVSがやることはありません。CVSは管理のための道具にはなりますが、道具自身が管理をすることはありません。付属マニュアルでは、CVSを楽器、プログラマを演奏者にたとえています。
■■■■CVSは開発者の間の意思疎通をとりもったりしません
あるファイルを複数の人が編集しているとコンフリクト（conflict＝競合）が起こることがあります。競合という言葉自体の意味は、同じファイルに加えられた二つの変更がとても近くにあるために、CVSがどちらを選んでよいかわからない状態になっているということです。細かいことをいえば、mergeコマンド（つまりdiff3コマンド）が混乱しちゃうほど変更が近くにあるということです。CVSは競合を検出しますが、その競合のどちらが正しいのかは結局、関係した人が話し合って調整しないと解決できません。せっかく自分がおこなった変更を、誰か他の人が勝手に元に戻してしまったら、普通怒りますよね。
さらに競合としてCVSが検出しないものもあります。同じファイルもしくはいくつかのファイルに同時に加えられた変更の中に、人間が考えると矛盾すると思うような点があっても、CVSにはわかりません。つまり、プログラムだったら論理的に矛盾しているような変更についても、十分に離れていればCVSにはわからないということです。
例えば、以前からあるファイルの中のある関数Xの引数をある人が変更したとしましょう。同じ時に、他の誰かが他のファイル（同じファイルでも構いませんが...）を編集して、古い引数を使ってXを呼び出したとします。CVSにはその変更の意味はわかりませんし、競合としても検出しません。きっとコンパイル時にエラーが出てびっくりすることでしょう。
競合であれ、そうでない矛盾であれ、CVSが人間に教えることができるのは、変更があったということと変更の内容だけです。このような問題は関係のある人と日頃から良く話し合って解決する必要があるということです。
■■■■CVSは変更管理（change control）はしません
まず、バグ追跡というのを変更管理と呼ぶことがあります。これはプログラム内に発見されたバグの報告とそれらのバグの状態（修正されたか？ どのリリースか？ 報告者は修正を確認したか？）をデータベースとして管理することです。CVSは、このバグ追跡を行いはしません。バグ追跡システムと連係したい場合には、CVSの管理用ファイルであるrcsinfoとeditinfoまたはverifymsgファイルを利用します。これらのファイルについては後で説明します。
一方、複数のファイルが同時に変更されたことを覚えておくことも変更管理と呼ばれます。例えば、関数への変更とその関数を利用したコードの変更を別々のファイルに対して行ったとき、これは意味的には一つの変更と考えられます。この変更を一括して管理する能力はありません。それらの複数のファイルの変更を一回のcvs commitにより登録したとしても、CVSはそれらのファイルを同時に登録したことを忘れてしまうのです。そして、それらのファイルを同時に登録したことを示す事項は、それらが同じログ・メッセージを持つことだけになります。GNUのChangeLogの形式でそれらをまとめておくという手段は有効です。ちなみに、perlで書かれたcvs2cl.plで同じログメッセージをひとまとめにして取り出し、ChangeLogを生成することができます。このツールについては、別途紹介します。
さらに、各変更の状態（どの変更がどの開発者によって加えられたかとか、その変更が他の開発者によって追試であるとかいった状態のこと）を覚えておく能力を、変更管理と呼ぶこともあります。一般的にCVSでこのようなことをするには、まず、一人patchを当てて登録する人を決めておき、変更した人は（cvs diffやdiffを用いて）差分を生成してその人にメールとして送るということをするようです。これは非常に融通のきく方法ではありますが、CVSの外部で行われるためCVSとしては何の保証もできません。
■■■■CVSは自動的にテストてくれたりはしません
ですが、CVSの管理ファイルである、「commitinfo」ファイルを使えば、どうしても必要だと思われる項目を強制的にテストするように設定できます。commitinfoの設定方法などについては、第6章で詳しく説明します。前版ではナゾだったこの項目ですが、近年注目を集めているeXtreme Programming(XP)という開発プロセスモデルについて調べるうちに、なるほどと思うようになりました。
XPでは「テストファースト」といって、ある機能モジュールを設計・実装するときに、まずインターフェースに対するテストを書かなくてはいけません。このテストはユニットテストと呼ばれ、JUnit、CppUnitなどユニットテストを補助するためのパッケージも出回っています。こうした、テストは毎回行わなければいけませんから、コミット時に自動的にテストされるように設定しておくのは、とても良い考えのように思えます。
XPについて詳しく知りたい方は以下のページをどうぞ。
▼eXtreme Programming FAQ
[http://objectclub.esm.co.jp/eXtremeProgramming/]
■■■■CVSは特定のプロセスモデル（process model）には基づいていません
プロセスモデルというのは、ソフトウェアの開発をどのようにおこなっていくかというモデルのことです。プロセスモデルにはウォーターフォールのような伝統的なものから、特殊なものまでさまざまなものがあります。詳しく知りたい人はソフトウェアプロジェクト管理というキーワードで検索してみてください。プロセスモデルにはソフトウェアの変更やリリースにおいておこなわれないといけない、様々な手順や承認事項が定義されます。いくつかの統合開発環境では特定のプロセスモデルに基づいて、その手順を確実におこなうようにしています。
CVSは特定のプロセスモデルに基づいてはいません。CVSを用いてなんらかのプロセスモデルを実現することはできるでしょうが、ちょっと面倒だと思います。commitinfo, loginfo, rcsinfo, verifymsg等の管理ファイルを用いて、ある変更を登録する前には必ずそのプロセスモデルに必要な動作を、おこなうように設定できはするということです。
なお、ブランチ（branch＝枝）やタグ（tag）といった機構を用いて、開発用のブランチを用意してその上で実験を繰り返し、十分安定性が証明された変更だけを安定化指向のブランチに統合することは実際良くおこなわれています。例えば、Linuxのカーネル、あるいはFreeBSDはそのシステム全体が、開発ブランチと安定（stable）ブランチにわけられて開発が進められています。
ソースコードの共有ということからは、上で紹介したXPなどは親和性が高いとは思いますが。
上で挙げた内容は、プログラム開発のための話が多かったので、結局開発者以外の方にはピンとこなかったかも知れません。まぁ少なくとも、今から少々大きなプログラムを開発をしようとしてCVSの利用を検討している方にはだいぶイメージが湧いたのではないでしょうか。ひとまず、ここではCVSというものを漠然とイメージして頂ければ幸いです。具体的なインストールについて第2章で、基本的な使い方については第3章で説明します。第4章以降は徐々に高度な使い方に移っていきます。みなさまの目的に合った使い方が見つかれば幸いです。