CVS はバージョン管理システムであり、 あなたのソース・ファイルの変遷を記録するのに使用します。
例えば、ソフトウェアの修正に伴なってバグが入り込み、 発見されるまでに長い時間がかかったとします。 CVS を使っていれば、古いバージョンを簡単に復元し、 バグの原因となった変更点を正確に調べることができます。 この特徴に救われる時が必ずあります。
全てのバージョンの全てのファイルを保存しておくこともできますが、 ディスク容量の無駄使いでしかありません。 CVS は、バージョン間の差分のみを保存する方法により、 各ファイルの全バージョンを一つのファイルに記録します。
CVS は、複数の開発者が同じソフトウェアに 取り組む場合に、真価を発揮します。 このような場合にはよほど気を付けていないと、 他の人が変更したファイルを上書きしてしまいます。 GNU Emacs のようなエディタを使えば、 複数の人が同時に同じファイルを編集することはありません。 しかし不幸なことに、全員が同じエディタを使うとは限りません。 CVS は開発者を互いに隔離することにより、この問題を解決しました。 全ての開発者は自分のディレクトリで作業し、 その仕事を CVS が組み合わせます。
CVS は Dick Grune が作成し、
1986年 12月に comp.sources.unix の volume 6 に投稿した、
シェル・スクリプトから始まりました。
現在の CVS は、
これらのシェル・スクリプトのコードを全く含みませんが、
衝突解決のアルゴリズムの大部分を受け継いでいます。
1989年 4月に Brian Berliner が CVS を設計し、コーディングしました。 その後、Jeff Polk が CVS の ベンダー枝とモジュールの設計を助けました。
CVS のソースは anonymous ftp で多くのサイトから 取得することができます。 例えば、prep.ai.mit.edu の `/pub/gnu' の中などです。 anonymous ftp でソースを取得する場合は、 ネットワーク全体の負荷を考えて、 なるべく近い所から取ってくるようにしましょう。
info-cvs という CVS 専門のメーリング・リストがあります。
参加したい場合、又は脱退したい場合には、
<info-cvs-request@prep.ai.mit.edu> にメールを出して下さい。
このメールには、あなたの email address を書いておいて下さい。
1996年 5月時点では、参加申込は忙しい人間の手で行われていますから、
参加や脱退が迅速に行われることを期待してはいけません。
また comp.software.config-mgmt は、
CVS の議論を行うのに適した場所です
(他の構成管理システムと一緒ですが)。
CVS は多くのことができますが、 全てのことはできません。
checkout 先のディスク容量の
使用法について指示したりはしません。
あなたが `Makefile' やスクリプトを全てのディレクトリで書き、
それらが各々全ての相対的な位置を知る必要があるとすると、
リポジトリ全てを取り出す必要が生じます。
あなたが仕事をモジュール化し、
(`Makefile' に link, mount, VPASS 等を使用して、)
ファイルを共有するような構築システムを構成すれば、
好きな様にディスクの利用法を決めることが出来ます。
しかしこれら全てのシステムは、
構築と維持に多大な労力が必要なことに、
気を付けなければいけません。
CVS は、このような問題に関して考慮しません。
もちろん、これらの構築システムを支援するための道具
(スクリプト, `Makefile' 等) は、
CVS の管理下に置くと良いでしょう。
何らかの変更があった際に、再構築が必要なファイルを調べるのは、
やはり CVS の守備外です。
伝統的な手法の一例をあげると、
構築には make を用い、
make に必要な依存関係は自動化されたツールを用いて生成します。
merge コマンド (つまり diff3) を驚かせるのに
十分なほど近接している場合にのみ生じます。
CVS は、
プログラムの論理に衝突があったとしても、
警告を表示しません。
例:
あなたは `A' で定義された関数 X の引数を変更したとします。
同じ時に、誰かが `B' を編集して、
古い引数を使って X を呼び出したとします。
これは CVS の能力の範囲外です。
仕様書を読み、同僚と話し合う習慣を付けましょう。
cvs commit により格納した場合、
CVS はそれらのファイルが同時に格納されたことを忘れてしまいます。
そして、それらのファイルを結ぶ事柄は、
同じログ・メッセージを持つことだけになるのです。
GNU 形式の `ChangeLog' を用いれば何らかの助けになるでしょう。
各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
開発者によって加えられた変更もあれば、
他の開発者によって追試中の変更もあるとか、そういったことです。
一般的に CVS でこのようなことをするには、
(cvs diff や diff を用いて) 差分を生成し、
patch を当てる人物にメールとして送ります。
これは非常に融通のきく方法ですが、
CVS 以外の機構に依存しているので、
問題が無いことを保証できません。
commitinfo ファイルを使えば、
強制的に必須の項目を検査することは可能だと思います。
しかし、
そんなことをしようとしたプロジェクトのことは聞いたことがありません。