| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 をインターネットからの自由なダウンロードなど、いろいろな方法 で取得することができます。 CVS のダウンロードや、他の CVS の 話題の情報は、以下のところを参照してください。
http://www.cyclic.com/ http://www.loria.fr/~molli/cvs-index.html |
info-cvs という CVS 専門のメーリング・リストがあります。
参加、又は脱退したい場合には、
info-cvs-request@gnu.org にメールを出して下さい。
Usenet グループの方を好むのであれば、正しいグループは
comp.software.config-mgmt で、CVS の議論を
するために適した場所です (他の構成管理システムと一緒で
すが)。 将来は comp.software.config-mgmt.cvs を
作ることも可能かもしれませんが、おそらく
comp.software.config-mgmt に十分な流量があるよう
になったときだけでしょう。
CVS かこのマニュアルのバグに対処する でより詳細に説明されている bug-cvs メーリン グリストを講読するともできます。講読するためには、 bug-cvs-request@gnu.org にメールを送ってください。
CVS は多くのことができますが、全ての人に全てのことを するようにはなっていません。
リポジトリと modules ファイルの構造と構築システム (例. `Makefile') とは相互作用するかもしれませんが、本質的 に独立したものです。
CVS は、何かの作り方を指示したりはしません。 CVS はあなたの意思に従って、 ツリー構造から望むファイルを取り出すだけです。
CVS は、checkout 先の作業ディレクトリのディスク容量の使用
法について指示したりはしません。あなたが `Makefile' やスクリプトを
全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
るとすると、リポジトリ全てを取り出す必要が生じます。
あなたが仕事をモジュール化し、(`Makefile' に link,
mount, VPATH等を使用して、)ファイルを共有するよ
うな構築システムを構成すれば、好きな様にディスクの利用
法を決めることが出来ます。
しかしこれら全てのシステムは、 構築と維持に多大な労力が必要なことに、 気を付けなければいけません。 CVS は、このような問題に関して考慮しません。
もちろん、これらの構築システムを支援するための道具 (スクリプト, `Makefile' 等) は、 CVS の管理下に置くと良いでしょう。
何らかの変更があった際に、再構築が必要なファイルを調べるのは、
やはり CVS の守備外です。
伝統的な手法の一例をあげると、
構築には make を用い、
make に必要な依存関係は自動化されたツールを用いて生成します。
CVS と結合して構築を行うための情報は 構築システムと CVS の関係方法 を参照してください。
あなたの管理者や上司は、期日に従っているかどうかや、 マージ点、枝の名前、リリースの日時等について、 あなたと度々話しあうことを求められています。 彼等がそうしないなら、CVS は役に立ちません。
CVS は、あなたの調律に従ってソースを踊らせる楽器の ようなものです。あなたは楽器奏者もしくは作曲者のような ものです。どんな楽器も勝手に演奏をしたりしないし、音楽 が勝手に書かれたりもしません。
あるファイルに衝突が起きた場合に、 ほとんどの開発者はそれほど苦労せずに解決します。 しかし、衝突 (conflict)のより一般的な定義には、 開発者同士の意志疎通なしには解決できない 困難な問題も含まれます。
同じファイル (もしくはファイルの集合) に、
同時に加えられた変更に論理的な衝突があっても、
CVS には分りません。
衝突という概念は単に文字列の比較によるもので、
同じファイルを基に加えられた二つの変更が、
merge コマンド (つまり diff3) を驚かせるのに
十分なほど近接している場合にのみ生じます。
CVS は、 プログラムの論理に、文字列でない衝突や、散らばった衝突 があったとしても、警告を表示しません。
例:
あなたは `A' で定義された関数 X の引数を変更したとします。
同じ時に、誰かが `B' を編集して、
古い引数を使って X を呼び出したとします。
これは CVS の能力の範囲外です。
仕様書を読み、同僚と話し合う習慣を付けましょう。
変更管理という言葉は様々な意味を持ちます。 まずバグ追跡と解釈すれば、バグ報告と各バグの状態 (修正されたか? どのリリースか? 報告者は修正を確認したか? ) についてのデータベース管理を意味します。 CVS とバグ追跡システムとの連携については、 `rcsinfo' と `editinfo' ファイルを見て下さい (see section 管理用ファイル便覧)。
論理的には一つと考えられる変更のため、
複数のファイルが同時に変更されたことを覚えておくことも、
変更管理と呼ばれます。
複数のファイルの変更を一つの cvs commit により格納した場合、
CVS はそれらのファイルが同時に格納されたことを忘れてしまいます。
そして、それらのファイルを結ぶ事柄は、
同じログ・メッセージを持つことだけになるのです。
GNU 形式の `ChangeLog' を用いれば何らかの助けになるでしょう。
各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
開発者によって加えられた変更もあれば、
他の開発者によって追試中の変更もあるとか、そういったことです。
一般的に CVS でこのようなことをするには、
(cvs diff や diff を用いて) 差分を生成し、
patch を当てる人物にメールとして送ります。
これは非常に融通のきく方法ですが、
CVS 以外の機構に依存しているので、
問題が無いことを保証できません。
commitinfo ファイルを使えば、
強制的に必須の項目を検査することは可能だと思います。
しかし、
そんなことをしようとしたプロジェクトのことは聞いたことがありません。
変更やリリースに必要とされる色々な手順や多くの承認を、 確実に行なう方法を備えたシステムもあります。 CVS を用いてこれを達成することも可能ですが、 ちょっと面倒だと思います。 場合によっては、 `commitinfo', `loginfo', `rcsinfo', `verifymsg' 等のファイルを用いて、変更点を格納する前に、 必要な手順を確実に踏むように設定できるでしょう。 また枝やタグといった機構を用いて、 開発用の枝で仕事を実行し、 安定性が証明された確実な変更だけを 安定化指向の枝に統合することも考えられます。
CVS を紹介する方法として、CVS を使って典型的な仕事をしてみま す。最初に理解すべきことは CVS は全てのファイルを中央に集められた リポジトリ (repository) (see section リポジトリ) に保存すると いうことです。この節ではリポジトリは準備されていると仮定します。
あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語 で書かれたファイルでできていて、`Makefile' を含んでいるとします。 このコンパイラを `tc' (Trivial Compiler) と呼ぶことにします。そし て `tc' というモジュール名でリポジトリに登録されています。
| 1.3.1 ソースの取得 | ||
| 1.3.2 変更の格納 | ||
| 1.3.3 お掃除 | ||
| 1.3.4 差分を見る |
まず、`tc' のソースの作業コピーを取ってくることから始めましょう。
これには checkout コマンドを使用します:
$ cvs checkout tc |
とすると `tc' という新しい作業ディレクトリが作られ、 その中にソース・ファイルがコピーされます。
$ cd tc $ ls CVS Makefile backend.c driver.c frontend.c parser.c |
`CVS' というディレクトリは CVS が内部的に使用 します。普通はその中にあるどんなファイルでも修正したり 削除してはいけません。
で、あなたの好きなエディタを用いて `backend.c' をハックして、 数時間後にコンパイラの最適化経路を加えたとします。 RCS と SCCS の利用者への注意: 編集したいファ イルをロックする必要はありません。その説明は、 See section 複数の開発者.
あなたはコンパイラが相変わらずコンパイル可能であることを確認し、 `backend.c' の新しいバージョンとすることに決めました。これは新し い `backend.c' をリポジトリに格納し、同じリポジトリを使っている他 の人が使用できるようにします。
$ cvs commit backend.c |
CVS はログ・メッセージを記すためにエディタを開きます。 そこで "Added an optimization pass." などと入力し、 一時ファイルに保存し、エディタを終了します。
どのエディタが開かれるかは環境変数 $CVSEDITOR により決定されま
す。$CVSEDITOR が設定されておらず、環境変数 $EDITOR が設
定されていれば、これを使用します。$CVSEDITOR と $EDITOR
の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
フォルトが使われます。例えば、unix では viで、Windows NT/95 で
は notepad です。
加えて、CVS は $VISUAL 環境変数も調べます。この動作が望ま
しいか、また CVS の将来のリリースが $VISUAL を調べるべきか
どうか、という意見は人によって異なります。$VISUAL が設定されて
いないか、$EDITOR に設定されていることを確実にすることで、どち
らになっても対処することができます。
CVS がエディタを開始したときは、修正されたファイルのリストを含ん
でいます。CVS のクライアントでは、このリストはファイルの修正時刻
を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
いないというときも、修正されたものとして表示されます。これに対する最も
簡単な対処法は単純に気にしないことです--それを commitすると、CVS
は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
す。次の updateはファイルが無修正であるという事実に基づき、将来
のセッションでファイルが表示されないように、タイムスタンプを保存されて
いるものに設定し直します。
わざわざエディタを開くのが嫌ならば、代わりにコマンド行の `-m' フ ラグを使うことでログメッセージを以下のように指定することができます:
$ cvs commit -m "Added an optimization pass" backend.c |
他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も ちろん、次のようにしても可能です
$ cd .. $ rm -r tc |
しかし、release コマンドを使用するほうが良いでしょう
(see section release--モジュールの放棄を表明する):
$ cd .. $ cvs release -d tc M driver.c ? tc You have [1] altered files in this repository. Are you sure you want to release (and delete) directory `tc': n ** `release' aborted by user choice. |
release コマンドは、あなたの修正が格納されているかどうか確認し
ます。ログを記録する設定ならば、ファイル `history' にメモします。
See section ファイル history.
release コマンドに `-d' フラグを使用すると、
確認と同時に作業コピーを削除します。
上の例では、release コマンドが何行か出力しています。
`? tc' は CVS が `tc' というファイルを知らないという意味です。
モジュール `tc' のことではなく、
生成したコンパイラ `tc' を指しており、
これはリポジトリに格納しなくて良いので無視して構いません。
この警告を消すための情報は cvsignore でファイルを無視する 参照。
release の出力の詳細な説明は release の出力 参照。
`M driver.c' の方は重要です。 これは、`driver.c' というファイルに加えた修正が、 格納されていないことを指摘しています。
release コマンドは、常に作業コピーの
修正が加えられたファイルの数を報告した後、
ファイルを削除したり履歴ファイルにメモする前に、
その確認を求めてきます。
ここでは大事を取って、最後に release が確認を求めたときに
n RET を入力しました。
あなたは `driver.c' に加えた修正を覚えていなかったので、 何をしたのか調べる必要があります。
$ cd tc $ cvs diff driver.c |
このコマンドは diff を実行して、取り出した時と、あなたの作業コ
ピーの `driver.c' のバージョンを比較します。その出力を見て、最適
化経路を有効にするオプションを、コマンド行で指定できるようにしたことを
思い出しました。その変更を格納して、このモジュールに対する作業を終了し
ます。
$ cvs commit -m "Added an optimization pass" driver.c Checking in driver.c; /usr/local/cvsroot/tc/driver.c,v <-- driver.c new revision: 1.2; previous revision: 1.1 done $ cd .. $ cvs release -d tc ? tc You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `tc': y |
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.