次: , 前: What is CVS?, 上: Overview


1.2 CVS は何ではない?

cvs は多くのことができますが、全ての人に全てのことを するようにはなっていません。

cvs は構築システムではありません。
リポジトリと modules ファイルの構造と構築システム (例. Makefile) とは相互作用するかもしれませんが、本質的 に独立したものです。

cvs は、何かの作り方を指示したりはしません。 cvs はあなたの意思に従って、 ツリー構造から望むファイルを取り出すだけです。

cvs は、checkout 先の作業ディレクトリのディスク容量の使用 法について指示したりはしません。あなたが Makefile やスクリプトを 全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ るとすると、リポジトリ全てを取り出す必要が生じます。

あなたが仕事をモジュール化し、(Makefile に link, mount, VPATH等を使用して、)ファイルを共有するよ うな構築システムを構成すれば、好きな様にディスクの利用 法を決めることが出来ます。

しかしこれら全てのシステムは、 構築と維持に多大な労力が必要なことに、 気を付けなければいけません。 cvs は、このような問題に関して考慮しません。

もちろん、これらの構築システムを支援するための道具 (スクリプト, Makefile 等) は、 cvs の管理下に置くと良いでしょう。

何らかの変更があった際に、再構築が必要なファイルを調べるのは、 やはり cvs の守備外です。 伝統的な手法の一例をあげると、 構築には make を用い、 make に必要な依存関係は自動化されたツールを用いて生成します。

cvs と結合して構築を行うための情報は Builds を参照してください。

cvs は管理者代理ではありません。
あなたの管理者や上司は、期日に従っているかどうかや、 マージ点、枝の名前、リリースの日時等について、 あなたと度々話しあうことを求められています。 彼等がそうしないなら、cvs は役に立ちません。

cvs は、あなたの調律に従ってソースを踊らせる楽器の ようなものです。あなたは楽器奏者もしくは作曲者のような ものです。どんな楽器も勝手に演奏をしたりしないし、音楽 が勝手に書かれたりもしません。

cvs は開発者同士の意志疎通の代用にはなりません。
あるファイルに衝突が起きた場合に、 ほとんどの開発者はそれほど苦労せずに解決します。 しかし、衝突 (conflict)のより一般的な定義には、 開発者同士の意志疎通なしには解決できない 困難な問題も含まれます。

同じファイル (もしくはファイルの集合) に、 同時に加えられた変更に論理的な衝突があっても、 cvs には分りません。 衝突という概念は単に文字列の比較によるもので、 同じファイルを基に加えられた二つの変更が、 merge コマンド (つまり diff3) を驚かせるのに 十分なほど近接している場合にのみ生じます。

cvs は、 プログラムの論理に、文字列でない衝突や、散らばった衝突 があったとしても、警告を表示しません。

例: あなたは A で定義された関数 X の引数を変更したとします。 同じ時に、誰かが B を編集して、 古い引数を使って X を呼び出したとします。 これは cvs の能力の範囲外です。

仕様書を読み、同僚と話し合う習慣を付けましょう。

cvs は変更管理をしません。
変更管理という言葉は様々な意味を持ちます。 まずバグ追跡と解釈すれば、バグ報告と各バグの状態 (修正されたか? どのリリースか? 報告者は修正を確認したか? ) についてのデータベース管理を意味します。 cvs とバグ追跡システムとの連携については、 rcsinfoeditinfo ファイルを見て下さい (see Administrative files)。

論理的には一つと考えられる変更のため、 複数のファイルが同時に変更されたことを覚えておくことも、 変更管理と呼ばれます。 複数のファイルの変更を一つの cvs commit により格納した場合、 cvs はそれらのファイルが同時に格納されたことを忘れてしまいます。 そして、それらのファイルを結ぶ事柄は、 同じログ・メッセージを持つことだけになるのです。 gnu 形式の ChangeLog を用いれば何らかの助けになるでしょう。

各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。 開発者によって加えられた変更もあれば、 他の開発者によって追試中の変更もあるとか、そういったことです。 一般的に cvs でこのようなことをするには、 (cvs diffdiff を用いて) 差分を生成し、 patch を当てる人物にメールとして送ります。 これは非常に融通のきく方法ですが、 cvs 以外の機構に依存しているので、 問題が無いことを保証できません。

cvs は自動検査プログラムではありません。
commitinfo ファイルを使えば、 強制的に必須の項目を検査することは可能だと思います。 しかし、 そんなことをしようとしたプロジェクトのことは聞いたことがありません。
cvs は手順規範を備えていません。
変更やリリースに必要とされる色々な手順や多くの承認を、 確実に行なう方法を備えたシステムもあります。 cvs を用いてこれを達成することも可能ですが、 ちょっと面倒だと思います。 場合によっては、 commitinfo, loginfo, rcsinfo, verifymsg 等のファイルを用いて、変更点を格納する前に、 必要な手順を確実に踏むように設定できるでしょう。 また枝やタグといった機構を用いて、 開発用の枝で仕事を実行し、 安定性が証明された確実な変更だけを 安定化指向の枝に統合することも考えられます。