[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

2. リポジトリ

CVSリポジトリ (repository) は、 バージョン管理の対象となる全てのファイルとディレクトリの、 完全なコピーを保管します。

通常、リポジトリ中のファイルを直接利用することはありません。 その代わりに CVS コマンドを使用して、 作業者自身のファイルのコピーを 作業ディレクトリ に取り出し、そのコピーを用いて作業します。

そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も しくは 格納 します (commit))。リポジトリは、変更を加えたも のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ とに注意してください。別の位置にあるべきです。

CVS は様々な方法でリポジトリを利用することができます。 リポジトリは、使用中のコンピュータ内であってもいいし、 別の部屋のコンピュータや、別の国のコンピュータであっても構いません。 リポジトリに接続する方法を区別するために、 リポジトリの名前の最初に接続経路 (access method) を加えることがあります。例えば :local: は、リポジトリ であるディレクトリを利用することを意味します。つまり :local:/usr/local/cvsroot で表されるリポジトリは、CVS を実 行したコンピュータの `/usr/local/cvsroot' というリポジトリを意味 します。他の接続経路については 別のマシンのリポジトリ 参照。

接続経路の指定が省略され、リポジトリに `:' が含まれない場合には、 :local: が仮定されます。 `:' が含まれていた場合には、 :ext::server: が仮定されます。 例えばリポジトリ `/usr/local/cvsroot' が同じコンピュータ内にある場合、 :local:/usr/local/cvsroot を省略して /usr/local/cvsroot と記述しても構いません。 しかし(Windows NT などで)、 リポジトリが `c:\src\cvsroot' にある場合、 :local:c:\src\cvsroot として、 接続経路を明示する必要があります。

リポジトリは二つの要素から構成されます。 `$CVSROOT/CVSROOT' には CVS の管理用ファイルが置かれます。 その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。


2.1 CVS にリポジトリの場所を教える

CVS にリポジトリの場所を教えるには、 いくつか方法があります。 一つ目はコマンド行で、 -d ("directory" を示します) オプションを用いて 指定する方法です:

 
cvs -d /usr/local/cvsroot checkout yoyodyne/tc

二つ目は、環境変数 $CVSROOT に、 絶対パスでリポジトリを指定する方法です。 例では `/usr/local/cvsroot'です。 cshtcsh のユーザは各々 `.cshrc' や `.tcshrc' に次の行を加えて下さい:

 
setenv CVSROOT /usr/local/cvsroot

shbash のユーザは各々 `.profile' や `.bashrc' に次の行を加えて下さい:

 
CVSROOT=/usr/local/cvsroot
export CVSROOT

-d によるリポジトリの指定は、 環境変数 $CVSROOT よりも優先されます。 一旦リポジトリから作業コピーを取得すれば、 リポジトリの場所が記憶されます (この情報は、作業ディレクトリ内の `CVS/Root' に記録されます)。

オプション -d とファイル `CVS/Root' は、 どちらも環境変数 $CVSROOT よりも優先されます。 また、`-d' と `CVS/Root' が一致しない場合は、 前者が使用されます。 もちろん、 二つともが同じリポジトリを参照するのが、まともなやり方です。


2.2 リポジトリでのデータの保存方法

CVS がリポジトリに情報を保存する方法を知っていても、 たいてい何の役にも立ちません。 実際、過去に書式が変更されましたし、 将来変更されることもあるでしょう。 ほとんど全ての場合、 CVS コマンドを通してリポジトリを利用しますから、 書式を変更しても混乱は起きません。

しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え ば CVS のロック解除が必要な場合 (see section 同時に CVS の実行を試みる複数の開発者) や、リポジ トリのファイルの許可属性を適切に設定する必要がある場合などです。


2.2.1 リポジトリのどこにファイルを保存するか

リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい ます。例えば、リポジトリが

 
/usr/local/cvsroot

にあれば、次のようなディレクトリの木構造になります (ディレクトリだけを 表示しています):

 
/usr
 |
 +--local
 |   |
 |   +--cvsroot
 |   |    | 
 |   |    +--CVSROOT
          |      (管理用ファイル)
          | 
          +--gnu
          |   | 
          |   +--diff
          |   |   (GNU diff のソース)
          |   | 
          |   +--rcs
          |   |   (RCS のソース)
          |   | 
          |   +--cvs
          |       (CVS のソース)
          | 
          +--yoyodyne
              | 
              +--tc
              |    |
              |    +--man
              |    |
              |    +--testing
              | 
              +--(その他の Yoyodyne のソフトウェア)

ディレクトリの中身は、管理下にあるファイルの履歴ファイル (history files) です。 履歴ファイルの名前は、各ファイル名の最後に `,v' を付加したものです。 次に、ディレクトリ `yoyodyne/tc' のリポジトリ構造を示します:

 
  $CVSROOT
    |
    +--yoyodyne
    |   |
    |   +--tc
    |   |   |
            +--Makefile,v
            +--backend.c,v
            +--driver.c,v
            +--frontend.c,v
            +--parser.c,v
            +--man
            |    |
            |    +--tc.1,v
            |
            +--testing
                 |
                 +--testpgm.t,v
                 +--test2.t,v

履歴ファイルは、 どのリビジョンのファイルでも再構築できる情報を持ち、 また変更内容が格納された時のログ・メッセージと、 その時のユーザの名前も記録しています。 ファイルをこのような書式で保管した最初のプログラムが、 RCS というバージョン管理システムであったために、 履歴ファイルは RCS ファイル と呼ばれます。 ファイル書式の完全な記述は、RCS の配布セットにある rcsfile(5)man ページか、CVS のソー ス配布のファイル `doc/RCSFILES' を参照してください。 このファイル書式は非常に一般的なので、 CVSRCS 以外のシステムでも、 少くとも理解をすることができます。

CVS で使用されている RCS ファイルは標準の書式と少し違います。 最大の違いは魔法の枝です。詳細は 魔法の枝番号 を参照して ください。CVS では、有効なタグ名は RCS で使用できるもののサ ブセットになっています。CVS の規則は タグ-文字によるリビジョン を参照してくださ い。


2.2.2 ファイル使用許可

全ての `,v' ファイルは読み込み専用であり、 この使用許可を変えるべきではありません。 これに対し、リポジトリ中のディレクトリは、 ファイルの修正を行なう人物に対して、 書き込みを許可しなくてはいけません。 これはつまり、 ファイルの修正を行なう人物からなるグループを作って (group(5)参照)、 そのディレクトリの所有グループとすることを意味しています。

従って、 ディレクトリ単位でしかファイルのアクセス権を 管理することができません。

CVS はロック・ファイルを作成する必要があるため (see section 同時に CVS の実行を試みる複数の開発者)、ファイルを取り出す使用者にも、書き込み許可が必 要であることに注意して下さい。

利用者は `CVSROOT/val-tags' ファイルに書き込み許可が必要なことも 注意してください。CVS はそれをどのタグが有効かを記録するために使 います (作成時と、ときどきタグが使用されたときに更新されます)。

それぞれの RCS ファイルは最後に書き込んだ利用者に所有されます。こ れはあまり重要ではありません。重要なのは誰がディレクトリを所有している かです。

木の中に新しいディレクトリを加える場合、 CVS はできるだけ適当な使用許可を与える努力をします。 しかし新しいディレクトリの使用許可が、 親ディレクトリのものと異なる必要がある場合には、 手動で変更する必要があります。 環境変数 CVSUMASK を設定すれば、 リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。 CVSUMASK は、作業ディレクトリのファイル使用許可には影響しません。 作業コピーの使用許可は、 新たに作成したファイルに通常与えられるものと同じです。 但し、CVS が読み込みだけを許可することがあります (監視時 監視するファイルを CVS に教える, -r 使用時 広域オプション, CVSREAD 設定時 CVS に影響する全ての環境変数 を各々参照)。

クライアント/サーバ CVS を使用すると (see section 別のマシンのリポジトリ)、CVSUMASK を設定する良い方法はありません。クライ アントマシンでの設定は効果がありません。rsh で接続しているなら、 オペーレーティングシステムの説明に書いてあるように、`.bashrc' や `.cshrc' で CVSUMASK を設定することができます。この振る舞 いは将来のバージョンの CVS では変更されるかもしれません。クライア ントの CVSUMASK の設定には頼らず、それは無効になるでしょう。

pserver を使う場合は、一般的に、 CVSROOT ディレクトリと木構造でそ れより上のディレクトリには厳しい使用許可が必要です。パスワード認証における安全性の考察 を参照してください。

オペレーティングシステムには特定のプログラムが、プログラムの呼び手には できないような動作をする能力とともに実行される機能があるものがあります。 例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や VMS の installed image 機能です。CVS はそのような機能を使用するように 書かれていませんので、そのような方法で CVS をインストールすると事故の 過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使 用許可を得るかもしれません。代わりに pserver を使用することを考えるか もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供 する可能性がありますので、このオプションを考えているなら、pserver の説 明文書を注意深く読んでください。(パスワード認証における安全性の考察)。


2.2.3 Windows に特有なファイルの使用許可問題

ファイルの使用許可には Windows オペレーティングシステムに特有の問題も あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、 確かではありません)。

ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる ことがあることが報告されています。Samba の設定で WRITE=YES にすると修 正される/何とかなると言われています。 責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調 査をしていません。加えて、問題を避けるために CVS が違ったようにするこ とができるかどうかも調べていません。何か発見したなら、CVS かこのマニュアルのバグに対処する に書 かれているように我々に報せてください。


2.2.4 The attic

ときどき CVSRCS ファイルを Attic に保存することが あることに気付くでしょう。例えば、CVSROOT が `/usr/local/cvsroot' でディレクトリ `yoyodyne/tc' のファイル `backend.c' について話をしているとき、普通はファイルは以下のとこ ろにあります

 
/usr/local/cvsroot/yoyodyne/tc/backend.c,v

しかし、attic に行けば、代わりに

 
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

になります。利用者にとってはファイルが attic にあるかどうかは関係あり ません。CVS はこれを記録し、必要なときは attic を調べます。詳細を 知りたい人のために書くと、幹の先頭リビジョンが dead の状態であ るまさにそのときだけ、ファイルは attic に保存されます。dead の 状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは dead の状態になり枝のリビジョンは dead ではない状態にな ります。


2.2.5 リポジトリの CVS ディレクトリ

それぞれのリポジトリのディレクトリの `CVS' ディレクトリはファイル 属性などの情報が収められています (`CVS/fileattr' というファイルで す。)。将来はこのディレクトリには他のファイルが加えられる可能性があり ますから、実装は追加のファイルを静かに無視するのが良いでしょう。

この動作は CVS 1.7 とその後のものだけで実装されています。詳細は 古いバージョンの CVS と監視機能 を参照してください。

fileattr ファイルの書式は以下の形式の登録の連続したものです (`{' と `}' は括弧の中のテキストを0回以上繰り返すことができるというこ とです):

ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>

ent-type はファイルでは `F' で、その場合は登録はそのファイ ルの属性を指定します。

ent-type が `D' で、filename が空であると、新しく追加 されたファイルへの既定属性を指定します。

他の ent-type は将来の拡張のために予約されています。CVS 1.9 とそ れ以前のものはファイル属性を書き込むときにいつでもそれらを消すでしょう。 CVS 1.10 とそれ以降はそれらを保存します。

行の順番は関係無いことに注意してください。 fileattr ファイルを書き込むプログラムは便利な様に再編成するかもしれま せん。

ファイル名でのタブとラインフィード、attrname での `=', attrval での `;'、などを引用する方法は今はありません。

習慣では、attrname は CVS により特別な意味を持っている属性は `_' で始まります。他の attrname は使用者定義の属性のために あります (もしくは、実装が使用者定義の属性のサポートを始めたときにそう なるでしょう)。

作りつけの属性です:

_watched

存在すると、ファイルが監視下にあり、読み込み専用で取り出すべきであるこ とを意味します。

_watchers

このファイルを監視している使用者です。値は watcher > type { , watcher > type } で、editor は使用者名、valtime+hostname+pathname で、timecvs edit コマンド (もしくはそれと等価なもの) が発生したときで、 hostnamepathname は作業ディレクトリのためです。

例:

 
Ffile1 _watched=;_watchers=joe>edit,mary>commit
Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs
D _watched=

は `file1' は読み込み専用で取り出されるべきだということです。加え て、joe は edit を監視しており、mary は commit を監視しています。ファ イル `file2' は読み込み専用で取り出されるべきです。sue は 1975年1 月8日にマシン workstn1 のディレクトリ `/home/sue/cs'編集を 始めました。この例を表現するために、`D', `Ffile1', `Ffile2' の後に空白を表示していますが、実際は単独のタブ文字がそこ にあり、空白があってはいけません。


2.2.6 リポジトリの CVS ロック

利用者から見える部分の CVS のロックに焦点をあてた紹介は 同時に CVS の実行を試みる複数の開発者 を参照してください。次の部分は同じリポジトリをアクセ スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう なツールを書きたい人を対象にしています。読み込みロック (read lock), 書き込みロック (write lock), デッ ドロック (deadlock) のような概念がよくわからなかったら、オペレー ティングシステムやデータベースの文献を参照すると良いかもしれません。

リポジトリ中の `#cvs.rfl.' で始まる全てのファイルは読み込みロック です。リポジトリ中の `#cvs.wfl' で始まる全てのファイルは書き込み ロックです。古いバージョンの CVS (CVS 1.5 以前) は `#cvs.tfl' で 始まる名前のファイルも作成していましたが、ここではそれらは議論しません。 ディレクトリ `#cvs.lock' はマスターロックとして働きます。すなわち、 他のロックを取得する前に、まずこのロックを取得しなければならない、とい うことです。

書き込みロックを取得するためには、まず `#cvs.lock' ディレクトリを 作成します。この操作は原子的操作でなければなりません (これはたいていの オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた めに失敗すれば、しばらく待ってもう一度試します。`#cvs.lock' ロッ クを取得した後、`#cvs.rfl.' の後に選択した情報 (例えば、ホスト名 とプロセス番号) が続いた名前のファイルを作成します。それからマスターロッ クを解放するために `#cvs.lock' ディレクトリを消去します。それから リポジトリを読んで続行します。終った後、読み込みロックを解放するために `#cvs.rfl' ファイルを消去します。

書き込みロックを取得するためには、読み込みロックと同様にまず `#cvs.lock' ディレクトリを作成します。それから `#cvs.rfl.' で始まるファイルが無いかどうかを調べます。もしあれば、`#cvs.lock' を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、 `#cvs.wfl' の後に選択した情報を続けた名前のファイルを作成します (例えば、ホスト名とプロセス番号)。ロック `#cvs.lock' を続けます。 リポジトリへの書き込みを実行します。それが終わると、まず `#cvs.wfl' ファイルを消去し、それから `#cvs.lock' ディレクト リを消去します。`#cvs.rfl' ファイルと違って、`#cvs.wfl' ファ イルは情報提供のためだけにあることに注意してください。`#cvs.lock' そのもののロックを続ける以上のロック操作の効果はありません。

それぞれのロック (書き込みロック及び読み込みロック) は `Attic' と `CVS' を含んだリポジトリの単独のディレクトリのみをロックしますが、 バージョン管理下の他のディレクトリは含まないことに注意してください。木 全体をロックするためには、それぞれのディレクトリをロックする必要があり ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため に再挑戦の前に木全体を解放しなければならないことに注意してください)。

CVS は個々の `foo,v' ファイルへのアクセス制御のために書き込 みロックを期待するということにも注意してください。RCS には `,foo,' ファイルがロックとして働く機構がありますが、CVS はそ れを実装しておらず、CVS の書き込みロックを取り出すことが推奨され ています。さらなる議論/合理性は CVS のソースコードの rcs_internal_lockfile のところのコメントを読んでください。


2.2.7 CVSROOT ディレクトリでファイルが保管される方法

`$CVSROOT/CVSROOT' ディレクトリにはいろいろな管理ファイルがありま す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て います。そこにはファイル名が `,v' で終わる多くの RCS ファイ ルがあり、多くの CVS コマンドは同じ方法でそれを操作します。しかし、 少しの違いはあります。

それぞれの管理ファイルには、RCS ファイルに加えて、ファイルの取り 出された版のコピーがあります。例えば、RCS ファイル `loginfo,v' とそれの最新リビジョンであるファイル `loginfo' があります。管理ファイルを格納したときは、CVS

 
cvs commit: Rebuilding administrative file database

を印字し、`$CVSROOT/CVSROOT' の取り出された版のコピーを更新するよ うになっています。もしそうならなければ、何かがおかしくなっています (see section CVS かこのマニュアルのバグに対処する)。自分自身のファイルをこのように更新されるファイル群に追 加するために、それらを管理ファイル `checkoutlist' に追加できます (see section checkoutlist ファイル)。

初期設定では `modules' ファイルは上で説明されているように振舞いま す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし て保存しているとモジュールの探索が遅くなるかもしれません (CVS が 最初にこの機能を追加したときほど関心があるかどうかは定かではありません。 ベンチマークは見ていませんので)。ですから、CVS ソースコードに適切 な修正を加えることで、modules ファイルを Berkeley db や GDBM のような ndbm インターフェースを実装したデータベースで保存することができ ます。このオプションが使用されると、modules データベースは `module.db', `modules' と/もしくは `modules.dir' に保存 されます。

いろいろな管理ファイルの意味に関する情報は 管理用ファイル便覧 を参照してください。


2.3 リポジトリでのデータの保存方法

しばしば表面に現れてくるかもしれない CVS の内部についての話をして いる間に、CVS が作業ディレクトリの `CVS' ディレクトリに何を 入れるかも話した方が良いでしょう。リポジトリと同様に、CVS がこの 情報を扱い、普通は CVS のコマンドを通してだけそれを使用します。で も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター フェース の jCVS や emacs のための VC パッケージなどの他 のプログラムがそれを見る必要があるかもしれません。そのようなプログラム は、上で書いたプログラムやコマンド行 CVS クライアントの将来のバー ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望 むなら、この節の推奨規格に従う必要があります。

`CVS' ディレクトリには複数のファイルがあります。このディレクトリ を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在 するけれどここで説明されていないファイルは静かに無視するのが望ましいで す。

ファイルは使用しているシステムのテキストファイルの習慣に従って保存され ます。これはテキストファイルの保管の習慣が違うシステム間では作業ディレ クトリは可搬性が無いということです。これは意図的になされていて、おそら く CVS で管理されているファイル自体がそのようなシステム間では可搬性が ないであろう、という理由に基づいています。

` Root'

このファイルは CVS にリポジトリの場所を教える で説明されているように、 現在の CVS のルートを保持しています。

` Repository'

このファイルは現在のディレクトリが対応するリポジトリでのディレクトリを 保持しています。指定は絶対パス名と相対パス名のどちらでも可能です。 CVS は少なくともバージョン 1.3 くらいから両方の形式を読み込む能力 を備えています。相対パスはルートからの相対位置で、より賢い方法ですが、 絶対パス名は非常によく使われており、実装は両方を受け付けることが望まれ ます。例えば、以下のコマンドの後で

 
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc

`Root' は以下のようになり

 
:local:/usr/local/cvsroot

`Repository' は

 
/usr/local/cvsroot/yoyodyne/tc

 
yoyodyne/tc

のどちらかになります。

特定の作業ディレクトリがリポジトリのディレクトリに対応しなければ、 `Repository' は `CVSROOT/Emptydir' になっているはずです。

` Entries'

このファイルは作業ディレクトリ中のファイルとディレクトリの一覧を挙げて います。 各行の最初の文字はそれがどんな行かを示します。将来の拡張ができるように、 文字を認識できない場合は、ファイルを読み込んでいるファイルは暗黙にその 行を飛ばすことが望まれます。

最初の文字が `/' であれば、様式は:

 
/name/revision/timestamp[+conflict]/options/tagdate

で、`[' と `]' は登録の一部ではありませんが、その代わりに `+' と衝突の印は省略任意であることを示しています。name はディ レクトリ中のファイルの名前です。revision は作業中のファイルの元 のリビジョンで、`0' の場合は追加されたファイル、`-' の後にリ ビジョンは削除されたファイルです。timestampCVS がファイ ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の 修正時刻と違えば、ファイルは修正されたということです。それは ISO C astime() 関数で使われる様式で保存されます (例えば、`Sun Apr 7 01:29:26 1996')。ファイルが常に修正されていると見なされるように、例え ば、`Result of merge' のようにその様式とは違う文字列を書くかもし れません。これは特別な場合ではありません。ファイルが修正されたかどうか を調べるために、プログラムはファイルのタイムスタンプを単純に timestamp と文字列比較をするべきです。衝突があれば、 conflict は、ファイルが衝突の印とともに書き込まれた後でファイル の修正時刻に設定することができます (see section 衝突の例)。 もし conflict がその後も実際の修正時刻と同じであるなら、ユーザは明か に衝突を解消していません。options は貼り付けられたオプションを保 持しています (例えば、バイナリ・ファイルのための `-kbd')。 tagdate は `T' の後にタグ名が続いているか、日付 (date) の `D' で、貼り付けられたタグか日付がつづいているかのどちらかを保持 しています。timestamp が単独のタイムスタンプではなく、スペースで 分離されたタイムスタンプの対であるなら、CVS 1.5 より前のバージョ ンの CVS を扱っているということに注意してください (ここでは説明さ れていません)。

CVS/Entries のタイムスタンプの標準時 (ローカルもしくは共通時) はオペレー ティングシステムがファイル自身のタイムスタンプとして保存するものと同じ である必要があります。例えば、Unix ではファイルのタイムスタンプは共通 時刻 (UT) ですので、CVS/Entries のタイムスタンプもそうなっているべきで す。VMS ではファイルのタイムスタンプはローカル時刻なので、 VMS 上の CVS はローカル時刻を使うべきです。この規則は、標準 時が変わったためだけでファイルが修正されたようにならないためです (例え ば、サマータイムになったり、それが終わったときなどです)。

`Entries' の行の最初の文字が `D' であると、それはサブディレ クトリを現しています。行が `D' だけのときは、 `Entries' ファ イルを書いたプログラムはサブディレクトリを記録したということを現します (ですから、そのような行があって、他に `D' で始まる行がなければ、 サブディレクトリがないことがわかります)。そうでなければ、行は次のよう になっています:

 
D/name/filler1/filler2/filler3/filler4

ここで name はサブディレクトリの名前であり、将来の拡張のために、 全ての filler 部分は暗黙の内に無視されるべきです。Entries を修正するプログラムはこれらの部分を保存するのが望まれています。

ファイル `Entries' 中の行はどんな順番でも構いません。

` Entries.Log'

このファイルは `Entries' に無いさらなる情報を記録することはありま せんが、`Entries' ファイル全体を再書き込みすることなく、情報を更 新するための方法をもたらし、その中には `Entries' と `Entries.Log' を書いているプログラムが不意に異常終了しても情報を 保護する機能もあります。`Entries' ファイルを読み込むプログラムは `Entries.Log' も調べるべきです。後者が存在すれば、`Entries' を読み込んで、`Entries.Log' にある変更を適用すべきです。変更を適 用した後で、`Entries' を再度書き込んで、`Entries' を消去する 習慣が推奨されています。`Entries.Log' の行の様式は、単独文字コマ ンドがあり、その後にスペースが続き、その後は `Entries' の行に指定 された様式になります。単独文字コマンドは登録が追加されたことを示す `A' と登録が消去されたことを示す `R' か、`Entries' の登 録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2 番目の文字が `Entries.Log' の行の2番目の文字がスペースでないと、 それは CVS の古いバージョンで書かれています (ここでは説明されてい ません)。

読み込みではなく、書き込みをしているプログラムは、もし望むならば `Entries.Log' ファイルを安全に無視することもできます。

` Entries.Backup'

これは一時ファイルです。推奨された使用法は、新しい Entriy ファイルを `Entries.Backup' に書き、それから `Entries' に改名する (もし 可能なら原子的操作で) ことです。

` Entries.Static'

このファイルが関連する唯一のことはそれが存在するか否か、ということです。 もし存在すると、ディレクトリの一部分だけが取得されていて、CVS は そのディレクトリに追加のファイルを作成しないということです。それを消去 するためには、update コマンドを `-d' オプションとともに使っ てください。そうすれば、追加のファイルを取得して、 `Entries.Static' を消去します。

` Tag'

このファイルはディレクトリごとの貼り付いたタグを保持します。最初の文字 は枝のタグには `T'、枝でないタグは `N'、日付は `D' にな り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付 は新規に追加されたファイルに適用されること等に使用されることに注意して ください。貼り付きタグと日付に関する一般的な情報は 貼り付いたタグ を参照してください。

` Checkin.prog'
` Update.prog'

これらのファイルはそれぞれ modules ファイルの `-i' と `-u' オプションで指定されたプログラムを保存します。

` Notify'

このファイルはまだサーバに送信されていない通知 (例えば、editunedit のため) を保存します。書式はまだここでは説明されていませ ん。

` Notify.tmp'

このファイルと `Notify' の関係は `Entries.Backup' と `Entries' の関係と同じです。即ち、`Notify' を書くためにはま ず新しい内容を `Notify.tmp' に書き、それから (可能であれば自動的 に) それを `Notify' に改名します。

` Base'

監視を使用していると、edit コマンドはファイルの元のコピーを `Base' ディレクトリに保存します。これで、サーバと通信できないとき でさえ unedit コマンドが実行できるようになります。

` Baserev'

このファイルは `Base' ディレクトリのそれぞれのファイルのリビジョ ンを一覧にします。書式は:

 
Bname/rev/expansion

で、expansion は将来の拡張のために、無視されるべきものです。

` Baserev.tmp'

このファイルと `Baserev' の関係は `Entries.Backup' と `Entries' との関係と同じです。即ち、`Baserev' に書くために、 まず新しい内容を `Baserev.tmp' に書き、それから (もし可能なら自動 的に) それを `Baserev' に改名します。

` Template'

このファイルには `rcsinfo' ファイルで指定された雛型が入っています (see section 管理用ファイル rcsinfo)。それはクライアントだけに使われます。非クライアント/ サーバ型 CVS は直接 `rcsinfo' ファイルを調べます。


2.4 管理用ファイルの紹介

`$CVSROOT/CVSROOT' には、いくつか 管理用ファイル (administrative files) があります。完全な説明は See section 管理用ファイル便覧. これらのファイルが無く ても CVS を使用することができます。しかし、少なくとも `modules' というファイルが適切に設定してあれば CVS のコマン ドはうまく働きます。

管理用ファイルの中で、 最も重要なファイルは `modules' です。 これはリポジトリの中の全てのモジュールを定義しています。 `modules' ファイルの例を次に示します。

 
CVSROOT         CVSROOT
modules         CVSROOT modules
cvs             gnu/cvs
rcs             gnu/rcs
diff            gnu/diff
tc              yoyodyne/tc

`modules' ファイルは行ごとに意味を持つファイルです。 `modules' ファイルの各行はそれぞれ、 モジュール名, 空白, モジュールのあるディレクトリ名 という書式で記述されます。 モジュールのあるディレクトリ名は、 $CVSROOT からの相対パスです。 `modules' ファイルの各行はそれぞれ、 モジュール名, 空白, モジュールのあるディレクトリ名 という書式で記述されます。 モジュールのあるディレクトリ名は、 $CVSROOT からの相対パスです。 上の例の最後の4行はそのような行の例です。

モジュール `modules' を定義する行については、 ここでは説明しません。 より詳しい説明は The modules file 参照。


2.4.1 管理用ファイルの編集

管理用ファイルは、 他のモジュールと同じ方法で編集します。 `cvs checkout CVSROOT' を用いて作業コピーを取り出して、 編集し、通常通り変更内容を格納します。

間違いのある管理用ファイルを格納することも可能です。 このような場合には、間違いを正して新たなリビジョンを登録します。 しかし管理用ファイルに深刻な間違いがあれば、 新たなリビジョンの登録さえも不可能になります。


2.5 複数のリポジトリ

特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変 数 $CVSROOT で設定するか、CVS のオプション `-d' に指 定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に CVS に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ けです。

複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。 CVS バージョン 1.10 では、単独のコマンドは違うリポジトリのディレ クトリを再帰的に辿ることはできません。開発バージョンの CVS では、 複数のサーバから作業ディレクトリに取り出すことがでます。CVS は要 求されたコマンドを実行するために必要であれば、再帰的に動作し、対応する 数のサーバ・マシンに接続するという細い作業全部を扱います。 以下は作業ディレクトリを設定する例です:

 
cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update

cvs co コマンドは作業ディレクトリを設定し、それから cvs update コマンドは server2 に接続し、dir1/sdir サブディレクトリを更新 し、その他のものを更新するために server1 に接続します。


2.6 リポジトリの作成

CVS リポジトリを設定するために、まずソースファイルのリビジョン履 歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも のですので、たいていのマシンは十分なはずです。詳細は サーバの要求 を参照してください。

ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを 移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、 バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同 じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、 全体の木かそれの一部分のどちらかになります)。

リポジトリはサーバ経由からか直接 CVS を使う全てのマシンからか、 (直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に する必要があります。クライアントのマシンは CVS プロトコル経由以外 でそれにアクセス可能である必要はありません。CVS は、リポジトリに ロック・ファイルを作成する必要があるため (see section 同時に CVS の実行を試みる複数の開発者)、利用者 が読み込み許可しか持たないリポジトリを、CVS から使うことはできま せん。

リポジトリを作成するときには、cvs init コマンドを実行して下さい。 通常の方法で指定された CVS のルート (see section リポジトリ) 以下の、 空のリポジトリを利用できるように整えます。例えば次のようにします。

 
cvs -d /usr/local/cvsroot init

cvs init は注意深いので、リポジトリに存在するファイルを上書きし ません。従って既に利用できる状態のリポジトリに対して cvs init を実行しても、何の不都合もありません。

cvs init は、操作履歴を記録するように設定します。 もしこれを望まないのであれば、cvs init を実行した後に、 `history' ファイルを削除して下さい。See section ファイル history.


2.7 リポジトリのバックアップ

リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき 点も幾つかあります。

最初の点は偏執的で、バックアップ中には CVS を使用しないか、バック アップ中はバックアッププログラムに CVS をロックさせる必要がありま す。CVS を使わないために、リポジトリを操作できるマシンへのログイ ンを禁止したり、CVS サーバを停止したり、同様な機構を利用するかも しれません。詳細はあなたのオペレーティングシステムと、CVS を設定 した方法に依存します。CVS をロックするためには、`#cvs.rfl' ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう に言ってきましたが、これらの事前注意をせずにただバックアップを行なって も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元 すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること が非常に難しいということは無いでしょう。

リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時 から変更されていると仮定すると、失敗に影響を受けなかったディレクトリは 今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし れません。そのようなディレクトリで CVS を実行しようとすると、普通 はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す 方法の一つに以下のようなものがあります:


2.8 リポジトリの移動

リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く 似ているように、リポジトリを別の場所に移動する必要があるときも、それは 他のファイルの集合を移動するのと非常に良く似ています。

主に考慮することは、作業ディレクトリがリポジトリを指しているか、という ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような 何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作 業ディレクトリを再利用したいなら、`CVS/Repository' ファイルを手で 手術することで可能です。`CVS/Repository' と `CVS/Root' ファ イルの情報は リポジトリでのデータの保存方法 で参照することができます が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。


2.9 別のマシンのリポジトリ

ソースの作業コピーはリポジトリと別のマシンに存在することができます。 CVS をこの方法で使うことは クライアント/サーバ (client/server) 操作として知られています。クライアント と して、CVS を作業ディレクトリを mount できるマシンで CVS を実 行し、サーバ となる、リポジトリを mount できるマシンと通信するよ うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式 が以下のようになることを除き、ローカルのものを使うのと同じです:

 
:method:user@hostname:/path/to/repository

どれが本当に設定する必要があるかは、サーバに接続している方法に依って変 わります。

method が指定されず、リポジトリ名に `:' が含まれる場合には、 使用するオペレーティングシステムに依って extserver が既定値とされます。詳しくは rsh で接続する 参照。


2.9.1 サーバの要求

サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は こじんまりとしたものであるということです--32M のメモリやそれ以下のサー バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。

もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の 見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分 が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで ないものがあれば、この説明文書を更新できるように、CVS かこのマニュアルのバグに対処する に書かれ ているように、我々に知らせてください)。

大量のメモリ消費をする最初の部分は、CVS サーバを使っているときの 大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための 2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな るか、2メガバイトほどかどちらか大きいものになることが予想されています。

それぞれの CVS サーバの大きさを予想上の一度に活動するサーバ数で掛 けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ リでしょう。

大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの diff です。これはバイナリ・ファイルでさえも必要です。大体の目安 は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が 適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ でなければ、CVS を実行しているマシン) に100メガバイトのメモリがあ るのが良いです。これは物理メモリでなく、スワップであるかもしれません。 メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ れるときのためのメモリを準備する必要は特にありません。

クライアントの資源消費はさらに少ないです--オペレーティングシステムを 動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。

ディスク容量に対する要求の情報は、リポジトリの作成 を参照し てください。


2.9.2 rsh で接続する

CVS はこれらの操作を実行するために `rsh' プロトコルを用いますので、 遠隔側の使用者のホストはローカルの使用者の接続を許可する `.rhosts' を持つ必要があります。

例えば、あなたがローカルマシン `toe.example.com' の利用者 `mozart' であり、サーバマシンは `faun.example.org' であると しましょう。faun では、以下の行を `bach' のホームディレクトリ の `.rhosts' ファイルに書いてください:

 
toe.example.com  mozart

そして、rsh の動作を次の行で確認します。

 
rsh -l bach faun.example.org 'echo $PATH'

次に rsh が、 サーバを発見できるかどうか確認する必要があります。 上記の例で rsh が表示したパスの中に、 サーバである cvs のあるディレクトリが 含まれているかどうか確認して下さい。 `.login' や `.profile' でなく、 `.bashrc', `.cshrc' 等に パスを設定する必要があります。 代わりに、クライアント側で環境変数 CVS_SERVER に、 `/usr/local/bin/cvs-1.6' などと、 使用したいサーバ名を設定できます。

`inetd.conf' を編集したり、 CVS のサーバ・デーモンを走らせる必要はありません。

rsh 経由で CVSROOT を利用するときに 指定できる接続経路は二つあります。 :server: を指定した場合、 CVS が内部実装した rsh のクライアントが用いられますが、 移植版では利用できないものもあります。 :ext: を指定した場合、外部の rsh プログラムが用いられます。 rsh が既定となっていますが、 サーバを利用できる他のプログラムを呼び出す場合は、 環境変数 CVS_RSH に設定して下さい (例えば HP-UX 9 では、 rsh は何か別のものなので remsh を用いて下さい)。 指定するプログラムは、データを変更しないで送受信できなくてはいけません。 例えば Windows NT の rsh は、 既定では CRLFLF に換えるので不適当です。 CVS の OS/2 版はこれを回避するため、 rsh に `-b' を渡して切り抜けていますが、 標準的な rsh でないプログラムを黙認する形になるので、 将来は別のやり方になるでしょう。 CVS_RSHSSH 等の rsh の代替物を設定した場合、 この節の残りの `.rhosts' の使用説明などは、 おそらく不適当でしょうから、 各 rsh の代替物の文書資料を参照して下さい。

例を続けます。仮に `faun.example.org' の リポジトリ `/usr/local/cvsroot/' 中の モジュール `foo' を利用したい場合には、 もう準備はできています:

 
cvs -d :ext:bach@faun.example.org:/usr/local/cvsroot checkout foo

(クライアント側とサーバ側で、使用者名が同じ場合には、 `bach@' を省略することが出来ます。)


2.9.3 パスワード認証による直接接続

CVS のクライアントは、 パスワード・プロトコルを用いて、 サーバと接続することもできます。 この方法は、 rsh の使用が可能でなく (例えばサーバが防火壁の向こうにある場合)、 またケルベロスも利用できない場合に特に有効です。

この方法を使用するために、 サーバとクライアント双方での調整が必要になります。


2.9.3.1 パスワード認証のためのサーバの設定

まず最初に、`$CVSROOT' と `$CVSROOT/CVSROOT' ディレクトリの 使用許可をきつくすることを考えるでしょう。詳細は パスワード認証における安全性の考察 を参照してください。

サーバ側では `/etc/inetd.conf' を編集する必要があります。 正しいポートに接続を受けた時、 inetd がコマンド cvs pserver を実行する様に変更します。 ポート番号の既定値は 2401 ですが、 クライアントをコンパイルした時に、 CVS_AUTH_PORT に他の値を定義した場合には異なります。

あなたの使用する inetd が、 ポート番号を素のまま `/etc/inetd.conf' に書いて良いならば、 次の記述で十分でしょう (`inetd.conf' には一行で記述して下さい):

 
2401  stream  tcp  nowait  root  /usr/local/bin/cvs
cvs -f --allow-root=/usr/cvsroot pserver

`-T' オプションで一時ファイルを作成するディレクトリも指定できます。

`--allow-root' オプションは使用可能な CVSROOT ディレクトリを 指定します。違う CVSROOT ディレクトリの使用を試みるクライアントは 接続できません。許可したい CVSROOT ディレクトリが2つ以上あるなら、 オプションを繰り返してください。(不幸なことに、inetd の多くのバー ジョンはコマンドと引数の両方、もしくはどちらかの長さ全体に対して非常に 小さくなるように制限を課しています。この問題に対する普通の解決は、 inetdCVS を必要な引数と共に起動するシェルスクリプトを 実行させることです。)

あなたの使用する inetd が、 素のポート番号ではなく、サービス名を要求するならば、 `/etc/services' に次の行を追加して下さい:

 
cvspserver      2401/tcp

そして `inetd.conf' には、 2401 ではなく cvspserver と記述して下さい。

以上を注意して行なった後、 inetd を再起動するか、 初期設定ファイルを再読させるのに必要な処置を取って下さい。

これの設定に問題があるときは、CVS サーバに接続をしようとするときの問題 を参照してください。

クライアントはパスワードを平文のまま保存または伝送します (ほぼそのように--詳細は パスワード認証における安全性の考察)。 従って、リポジトリを利用する時に、 正規のパスワードを危険に曝さないために、 CVS では普通は別のパスワードファイルを使用します。 このファイルは `$CVSROOT/CVSROOT/passwd' です。 欄が少ないことを除けば、Unix システムでの `/etc/passwd' と同様に コロンで分割した書式を使います: CVS 使用者名、省略可能なパスワード、認証が成功したかのように 実行するためにサーバが使用する任意に省略可能な使用者名です。 次に5つの登録がある `passwd' ファイルを例示します:

 
anonymous:
bach:ULtgRLXo7NRxs
spwang:1sOp854gDF3DY
melissa:tGX1fS8sun6rY:pubcvs
qproj:XR4EZcEs0szik:pubcvs

パスワードは、標準 Unix の関数 crypt() によって暗号化されます。 従って、標準 Unix の `/etc/passwd' から直接コピーすることも可能です。

例の最初の行は使用者 anonymous として認証しようとする全ての CVS クライアントに空パスワードなど、パスワードに関わらず、使用を 許可します。(これは匿名読み込み専用アクセスを許可するサイトでよく することです。"読み込み専用" の方法は 読み込み専用リポジトリ接続 を参照し てください。)

2行目と3行目は bachspwang がそれぞれ平文のパスワード を提供した場合にアクセスを許可します。

4行目は mellisa が正しいパスワードを使用したときにアクセスを許 可しますが、彼女の CVS での操作はサーバではシステムユーザ pubcvs として行われます。ですから、melissa という名前の システム使用者は必要ではありませんが、pubcvs という名前の使用者 は存在している必要があります

5行目はシスステムユーザは共有できることを示しています。qproj と して認証を成功した全てのクライアントは melissa と同様に、実際は pubcvs でして実行します。そのようにすることで、リポジトリ中にそ れぞれのプロジェクトごとに単独の共有ユーザを作成することができ、それぞ れの開発者に `$CVSROOT/CVSROOT/passwd' ファイルで専用の行を与える ことができます。それぞれの行の CVS 使用者名は違うかもしれませんが、 システムの使用者名は同じです。別の CVS 使用者名を使う理由は、CVS は操作をそれらの名前で記録するからです: melissa が変更をプロジェ クトに書き込むと、その格納はプロジェクトの履歴に pubcvs ではな く、melissa の名前で記録されます。システムのユーザ名を共有する 理由は、リポジトリの該当する部分の使用許可を、そのアカウントのみが書き 込み許可を持つように設定することができるからです。

CVS はシステム認証を行なうこともできます。 パスワード認証では、まずサーバが、`$CVSROOT/CVSROOT/passwd' ファイル中の、使用者のエントリを確認します。 使用者のエントリがあれば、そのエントリを上で説明された様に 認証に使用します。 ユーザを発見できないか、CVS の `passwd' ファイルが 存在しない場合には、オペレーティングシステムの使用者の調査機構を 使って使用者名とパスワードとの認証を試すことができます。 (この失敗時の動作は `config' ファイルで SystemAuth=no を 設定することで、使用不能にすることができます)。 しかしながら、システムの認証に立ち戻ることは安全性の面で 危険を冒すことになるかもしれないことには注意してください: CVS の操作はそのユーザの普通のログインパスワードで認証され、 パスワードはネットワークを平文で流れます。詳しくは パスワード認証における安全性の考察 を参照してください。

現在、 CVS の `passwd' ファイルにパスワードを加えるには、 他のどこかからコピーするしか方法がありません。 いつの日か cvs passwd コマンドができることでしょう。

`$CVSROOT/CVSROOT' の多くのファイルと違って、`passwd' ファイ ルは CVS 経由ではなく、直接編集するのが普通です。 これは`passwd' ファイルが作業コピーに含まれているセキュリティの 危険性のためです。`passwd' ファイルを `$CVSROOT/CVSROOT' を チェックアウトに含めたい場合は checkoutlist ファイル を参照してください。


2.9.3.2 パスワード認証によるクライアントの使用

CVS コマンドをパスワード認証サーバを通じて遠隔リポジトリで実行 するためには、pserver プロトコル、使用者名、リポジトリのホスト、 リポジトリへのパスを指定します。例えば:

 
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout someproj

もしくは、

 
CVSROOT=:pserver:bach@faun.example.org:/usr/local/cvsroot
cvs checkout someproj

しかし、全員に使用可能なリポジトリ (すなわち、使用者名がパスワードを要 求しないもの) でない限り、最初に ログイン しなければなりません。 ログインはリポジトリのパスワードを認証します。これは login コマ ンドで行われ、対話的にパスワード認証を促します。

 
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login
CVS password:

パスワードを入力し終わると、CVS がサーバで認証します。認証が成功 すれば、その使用者名、ホスト、リポジトリ、パスワードが永久に記録されま す。ですから、将来のリポジトリでの通信は cvs login の実行を要求 しません。(認証が失敗すれば、CVS はパスワードが正しくないことを言っ た後終了し、何も記録されません。)

既定では、登録はファイル `$HOME/.cvspass' に保存されます。ファ イルの形式は人間が読めるもので、ある程度人間が編集可能でもありますが、 パスワードは平文で保存されているのではないことは注意してください--そ れらは "純真な" 侵入 (つまり、システム管理者や他の悪意のない人間が不 注意に見るといった事) を防ぐため、簡単な符号化がされています。

このファイルの既定の場所を CVS_PASSFILE 環境変数を設定すること で変更することができます。 この変数を使用するのであれば、 cvs login を実行する前に設定しなければいけません。 cvs login を実行した後に設定した場合、 その後の CVS コマンドは、 サーバに送るパスワードを見付けられません。

一度ログインをすると、その遠隔リポジトリを使う全ての CVS のコマン ドは保存されたパスワードで認証します。ですから、例えば

 
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo

はそのまま動作します (サーバ側でパスワードが変更されない限り。その場合 は cvs login をもう一度実行する必要があります)。

リポジトリ指定中に `:pserver' が存在していなければ、CVS は変 わりに rsh で接続すると仮定することに気を付けてください (see section rsh で接続する)。

もちろん、一度作業コピーを取り出してそこから CVS のコマンドを実行 していれば、明示的にリポジトリを指定する必要は無くなります。というのは、 CVS は作業コピーの `CVS' サブディレクトリから導き出すことが できるからです。

任意の遠隔リポジトリのパスワードは cvs logout コマン ドを使用すると CVS_PASSFILE から消去できます。


2.9.3.3 パスワード認証における安全性の考察

パスワードは、 平文を簡単に符号化してクライアント側に保存されており、 送信の際も同じ符号化が用いられます。 この符号化は、パスワードが偶然見られること (すなわちシステム管理者が 不注意に見てしまう事) を防ぐためのもので、 素人の攻撃からパスワードの取得を防ぐことさえ出来ません。

CVS 独自のパスワードファイルにより (see section パスワード認証のためのサーバの設定)、 リポジトリを利用する時には、 システムにログインする時とは別のパスワードが使用できます。 しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、 多様な方法により、サーバ上でプログラムが実行可能になります。 つまりリポジトリの利用は、 かなり広範囲にシステムが利用できる事を暗示しています。 これを防止するように CVS を修正する事は可能でしょうが、 これを書いている時点までには誰もやっていません。

`$CVSROOT/CVSROOT' ディレクトリには `passwd' と他のセキュリ ティを調べるために使われるファイルがあるので、このディレクトリの使用許 可をを `/etc' と同じくらいきつくしなければならないことに注意して ください。同じことが `$CVSROOT' ディレクトリそのものと、木のそれ より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが できます。これらの使用許可は普通は pserver を使っていないときに使用す るものよりもきついものであることに注意してください。

要約すると、 パスワードを得た人物は誰でもリポジトリを利用できます (これはまたある程度通常のシステム利用も可能になるということを含むかも しれません。) ネットワークのパケットを漁ったり、 保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、 全ての人物がパスワードを入手可能です。 あなたが本物の安全を望むのならば、ケルベロスにしましょう。


2.9.4 GSSAPI による直接接続

GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般 的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、 CVS を GSSAPI で認証して、直接 TCP 接続を通して接続すること ができます。

これをするためには、CVS が GSSAPI サポート付きでコンパイルされて いる必要があります。CVS を configure しているときに、ケルベロス version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま す。構築するために `--with-gssapi' も使用できます。

接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認 証されません。ストリームの認証を要求するためには、広域オプショ ン -a を使用する必要があります。

既定状態では、データ転送は暗号化されません。 クライアントとサーバ双方を、 暗号化を有効にしてコンパイルしておく必要があります。 構築時に `--enable-encryption' オプションを付加して、 暗号化機能を有効にして下さい。 また暗号化を要求するために、 使用時に広域オプション `-x' を付加する必要があります。

GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ れます。パスワード認証のためのサーバの設定 参照。ケルベロスのような 強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ る認証を使用不能にしたいと思うかもしれません。そのためには、空の `CVSROOT/passwd' パスワードファイルを作成して、config ファイルで SystemAuth=no を設定します (see section The CVSROOT/config configuration file)。

GSSAPI サーバは cvs/hostname の主な名前を使い、hostname は サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ うにこれを設定しなければなりません。

GSSAPI を使用して接続するには、`:gserver:' を使用します。例えば、 以下のようになります。

 
cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo

2.9.5 ケルベロスによる直接接続

ケルベロスを使う一番簡単な方法は rsh で接続する で説明されて いるようにケルベロスの rsh を使用することです。 rsh を利用する際の主な欠点は、 全てのデータが他のプログラムを経由する必要があるため、 時間がかかるかもしれない事です。 もしケルベロスが導入されているならば、 ケルベロスの認証により、直接 TCP 接続する事が可能です

この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関 するものです。ケルベロス バージョン5は前節で説明されているように、 GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ うになっています。

このためには、 ケルベロスの支援を受けるように CVS をコンパイルする必要があります。 CVS は configre 時に ケルベロスが利用できるかどうかを検出しようとしますが、 駄目ならフラグ `--with-krb4' を用いて強制させることも可能です。

既定状態では、データ転送は暗号化されません。 クライアントとサーバ双方を、 暗号化を有効にしてコンパイルしておく必要があります。 構築時に `--enable-encryption' オプションを付加して、 暗号化機能を有効にして下さい。 また暗号化を要求するために、 使用時に広域オプション `-x' を付加する必要があります。

サーバの `inetd.conf' を編集する必要があります。 クライアントが使用する既定のポート番号は 1999 です。 他のポートを使用したい場合には、 クライアントの環境変数 CVS_CLIENT_PORT で指定して下さい。

CVS を利用する前に、 通常の方法で切符を取得して下さい (一般的には kinit です)。 この切符でサーバへのログインが許可されるはずです。 これで準備ができました:

 
cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo

ここで接続に失敗した場合、 以前のバージョンの CVS は rsh で再接続を試みましたが、 このバージョンでは再試行されません。


2.9.6 fork を通じての接続

この接続方法で、ローカル・ディスクのリポジトリに遠隔プロトコルを使って 接続することができます。言い換えると、それは :local: とほとんど 同じことをしますが、変な振舞いや、バグやその他のものはローカルの CVS のものではなく、遠隔 CVS のものです。

毎日の作業では、:local::fork: を好むかは個人の好みに 依ります。もちろん :fork:cvs と遠隔プロトコルをデバッ グしているときは特に役立ちます。特に、我々は他の遠隔アクセス方法のネッ トワーク関連の設定、変更、時間切れ設定、認証全てを避けることができ、そ の上で遠隔プロトコルを使う接続を作成することができるのです。

fork 方法を用いて接続するためには、`:fork:' とローカルのリ ポジトリへのパス名を使用します。例えば、:

 
cvs -d :fork:/usr/local/cvsroot checkout foo

:ext: と同様に、サーバは既定値の `cvs' と呼ばれるか、 CVS_SERVER 環境変数の値になります。


2.10 読み込み専用リポジトリ接続

パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める ことができます (see section パスワード認証による直接接続)。 (他の接続方法は全て リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用 許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助 はありません。)

読み込み専用接続の使用者は、特定の "管理" ファイル (ロックファイルや 履歴ファイル) を除いて、リポジトリを変更しない CVS の操作のみを実 行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ う (see section パスワード認証のためのサーバの設定)。

以前のバージョンの CVS と違って、読み込み専用使用者はリポジトリを 読むことができるだけで、サーバのプログラムを実行できないようになってい るはずです。そうしないと、予期しないレベルの接続を得ることができてしま います。もしくは、より正確に言うと、既知の穴は塞がれました。こ の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ リティへの関心に従って、どのような程度の注意も払うべきというのは正当の ようです。

使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除 です。

"包含" は、使用者を特別に `$CVSROOT/CVSROOT/readers' ファイルに一 覧表示するということで、それは単純な改行で分離された利用者の一覧です。 これは `readers' ファイルの例です:

 
melissa
splotnik
jrandom

(最後の使用者の後の改行を忘れないでください。)

"排除" は 書き込み 接続のできる人を全て明示的に一覧表示するとい うことです--もしファイル

 
$CVSROOT/CVSROOT/writers

が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その 他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相 変らず CVS `passwd' ファイルに挙げられている必要があります。) `writers' ファイル は `readers' ファイルと同じ書式です。

注意: CVS `passwd' ファイルが cvs の使用者をシステムの使用者 にマップしているときは、cvs の使用者名を使って書き込み専用接続 を拒否したり認めたりしていて、システムの使用者名を使っていないことを確 認してください。すなわち、`readers' と `writers' ファイルに cvs の使用者名があるということで、それはシステムの使用者名と同じかもし れませんし、違うかもしれません。

これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ の振舞いの完全な説明です。

`readers' が存在して、この使用者がそこに挙げられていれば、読み込 み専用接続になります。もしくは、`writers' が存在していて、使用者 がそこに挙げられていなければ読み込み専用接続になります (`readers' が存在するけれど、そこには挙げられていないというときにもそのようになり ます)。その他の場合では、完全な読み込み書き込み接続になります。

もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。 これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより 多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな ります。


2.11 サーバの一時ディレクトリ

CVS サーバは実行中に一時ディレクトリを作成します。それは

 
cvs-servpid

のような名前で、pid はサーバのプロセス番号です。それらは環境変数 TMPDIR (see section CVS に影響する全ての環境変数)、`-T' 広域オプショ ン (see section 広域オプション)、で指定されるディレクトリもしくは、それら がないと `/tmp' に置かれます。

ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時 ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな い場合がいくつかあります。例えば:

このような場合は、手で `cvs-servpid' ディレクトリを消去する 必要があります。プロセス番号 pid で動いているサーバが無ければ、 その行為は安全です。


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.