最初, 戻る, 進む, 最後, 目次 に行く。


1 CVS とは?

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 は ... ではない

CVS は多くのことができますが、 全てのことはできません。

CVS は構築システムではありません。
あなたの構築システム用のファイル (例えば `Makefile' 等) をリポジトリ中に格納する ことはできますが、構築システムとは全く独立した存在です。 CVS は、何かの作り方を指示したりはしません。 CVS はあなたの意思に従って、 ツリー構造から望むファイルを取り出すだけです。 CVS は、checkout 先のディスク容量の 使用法について指示したりはしません。 あなたが `Makefile' やスクリプトを全てのディレクトリで書き、 それらが各々全ての相対的な位置を知る必要があるとすると、 リポジトリ全てを取り出す必要が生じます。 あなたが仕事をモジュール化し、 (`Makefile' に link, mount, VPASS 等を使用して、) ファイルを共有するような構築システムを構成すれば、 好きな様にディスクの利用法を決めることが出来ます。 しかしこれら全てのシステムは、 構築と維持に多大な労力が必要なことに、 気を付けなければいけません。 CVS は、このような問題に関して考慮しません。 もちろん、これらの構築システムを支援するための道具 (スクリプト, `Makefile' 等) は、 CVS の管理下に置くと良いでしょう。 何らかの変更があった際に、再構築が必要なファイルを調べるのは、 やはり CVS の守備外です。 伝統的な手法の一例をあげると、 構築には make を用い、 make に必要な依存関係は自動化されたツールを用いて生成します。
CVS は管理者代理ではありません。
あなたの管理者や上司は、期日に従っているか, マージ点, 枝の名前, リリースの日時等について、 あなたと度々話しあうことを求められています。 彼等がそうしないなら、CVS は役に立ちません。 CVS は、あなたの調律に従ってソースを踊らせる楽器のようなものです。 あなたは楽器奏者もしくは作曲者だとしましょう。 どんな楽器も勝手に演奏をしたりしないし、 音楽が勝手に書かれたりもしません。
CVS は開発者同士の意志疎通の代用にはなりません。
あるファイルに衝突が起きた場合に、 ほとんどの開発者はそれほど苦労せずに解決します。 しかし、衝突 (conflict) のより一般的な定義には、 開発者同士の意志疎通なしには解決できない 困難な問題も含まれます。 同じファイル (もしくはファイルの集合) に、 同時に加えられた変更に論理的な衝突があっても、 CVS には分りません。 衝突という概念は単に文字列の比較によるもので、 同じファイルを基に加えられた二つの変更が、 merge コマンド (つまり diff3) を驚かせるのに 十分なほど近接している場合にのみ生じます。 CVS は、 プログラムの論理に衝突があったとしても、 警告を表示しません。 例: あなたは `A' で定義された関数 X の引数を変更したとします。 同じ時に、誰かが `B' を編集して、 古い引数を使って X を呼び出したとします。 これは CVS の能力の範囲外です。 仕様書を読み、同僚と話し合う習慣を付けましょう。
CVS は変更管理をしません。
変更管理という言葉は様々な意味を持ちます。 まずバグ追跡と解釈すれば、バグ報告と各バグの状態 (修正されたか? どのリリースか? 修正を確認した人物は? 等) についてのデータベース管理を意味します。 CVS とバグ追跡システムとの連携については、 `rcsinfo'`editinfo' ファイルを見て下さい (「B 管理用ファイル便覧」参照)。 論理的には一つと考えられる変更のため、 複数のファイルが同時に変更されたことを覚えておくことも、 変更管理と呼ばれます。 複数のファイルの変更を一つの cvs commit により格納した場合、 CVS はそれらのファイルが同時に格納されたことを忘れてしまいます。 そして、それらのファイルを結ぶ事柄は、 同じログ・メッセージを持つことだけになるのです。 GNU 形式の `ChangeLog' を用いれば何らかの助けになるでしょう。 各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。 開発者によって加えられた変更もあれば、 他の開発者によって追試中の変更もあるとか、そういったことです。 一般的に CVS でこのようなことをするには、 (cvs diffdiff を用いて) 差分を生成し、 patch を当てる人物にメールとして送ります。 これは非常に融通のきく方法ですが、 CVS 以外の機構に依存しているので、 問題が無いことを保証できません。
CVS 自動検査プログラムではありません。
commitinfo ファイルを使えば、 強制的に必須の項目を検査することは可能だと思います。 しかし、 そんなことをしようとしたプロジェクトのことは聞いたことがありません。
CVS は手順規範を備えていません。
変更やリリースに必要とされる色々な手順や多くの承認を、 確実に行なう方法を備えたシステムもあります。 CVS を用いてこれを達成することも可能ですが、 ちょっと面倒だと思います。 場合によっては、 `commitinfo', `loginfo', `rcsinfo', `editinfo' 等のファイルを用いて、変更点を格納する前に、 必要な手順を確実に踏むように設定できるでしょう。 また枝やタグといった機構を用いて、 開発用の枝で仕事を実行し、 安定性が証明された確実な変更だけを 安定化指向の枝に統合することも考えられます。


最初, 戻る, 進む, 最後, 目次 に行く。