[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

Repository Administration

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Repository%20Administration"
"j-cvsbook/RepositoryAdministration"へのコメント(無し)
検索全文Elisp

An Overview of CVS ではプロジェクトの一参加者として CVS を使う方 法を学びました。が、プロジェクト管理者になる場合にはそれに加え、CVS の インストールとリポジトリ管理の方法を知る必要があります。この章では、リ ポジトリがどういう構造になっていて CVS がそれをどう使っているかを、カー テンを取って詳しく見ます。また、アップデートやコミットの際に CVS が通 過する主なステップと、その動作の変更のしかたを学びます。CVS がどのよう に動いているかを理解すれば、問題が起こった時に原因を調べて、保守性のよ いやりかたで解決することもできます。

とても involved に聞こえるかもしれませんが、CVS は長生きすることは間違 いなく、何年も使うことになるでしょう。今から勉強することは長い間役に立 つことになるのです。CVS は使えば使うほど不可欠になります。何かに頼ろう とする時には(絶対そうなるって)、それを知る価値があるのです。

ということを心に留めておいて、始めましょう。まずは CVS をあなたのシス テムに導入するところから。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.5 Getting And Installing CVS

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Getting%20And%20Installing%20CVS"
"j-cvsbook/A.5GettingAndInstallingCVS"へのコメント(無し)
検索全文Elisp

既にシステムに入っていて、わざわざ CVS を取りに行ったり必要はないこと が多いです。主な Linux や FreeBSD のディストリビューションを使っている 場合には、/usr/bin とかにインストールされていると思います。インストー ル済みでなくても、Red Hat Linux ユーザなら最新またはほとんど最新の CVS の RPM (Red Hat Package) がディストリビューションにあります。Debian ユー ザなら以下のコマンドでインストールできます:

 
floss$ apt-get update
floss$ apt-get install cvs

CVS がマシン上にない場合はソースから作ります。Unix ユーザでない場合は その OS 用のバイナリが見つかると思います。幸い CVS は autoconfiscated で、GNU autoconf を使ってソースのコンパイルが非常に簡単になっています。

A.5.1 Getting And Building CVS Under Unix  
A.5.2 Getting And Installing CVS Under Windows  
A.5.3 Getting And Installing CVS On A Macintosh  
A.5.4 Limitations Of The Windows And Macintosh Versions  



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.5.1 Getting And Building CVS Under Unix

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Getting%20And%20Building%20CVS%20Under%20Unix"
"j-cvsbook/A.5.1GettingAndBuildingCVSUnderUnix"へのコメント(無し)
検索全文Elisp

これを書いている時点で、CVS の正規ダウンロードサイトが2つあります。ひ とつはフリーソフトウェアファウンデーション(FSF)のFTPサイト ftp:/ /ftp.gnu.org/gnu/cvs/ で、公式な GNU ツールとして CVS を提供していま す。Cyclic Software は CVS のメンテナ、じゃなくて「メンテナのメンテナ」 で、ユーザと開発者向けにリポジトリサーバとダウンロードサイトを提供して います。http://download.cyclic.com/pub/ でリリースを配布してい ます。

どちらでもかまいません。下の例では Cyclic Software のサイトを利用しま した。FTP クライアント(ウェブブラウザかもしれません)でそこへアクセスす るとディレクトリ一覧が見えます、こんな感じ:

 
Index of /pub
    cvs-1.10.5/            18-Feb-99 21:36      -  
    cvs-1.10.6/            17-May-99 10:34      -  
    cvs-1.10/              09-Dec-98 17:26      -  
    macintosh/             23-Feb-99 00:53      -  
    os2/                   09-Dec-98 17:26      -  
    packages/              09-Dec-98 17:26      -  
    rcs/                   09-Dec-98 17:26      -  
    tkcvs/                 09-Dec-98 17:26      -  
    training/              09-Dec-98 17:26      -  
    unix/                  09-Dec-98 17:26      -  
    vms/                   09-Dec-98 17:26      -  

「cvs-」で始まるディレクトリに注意して下さい(ほかのは無視して構いませ ん)。cvs- ではじまるディレクトリは3つあって、ここで選択せねばなりませ ん: 安定した(stable)リリースがいいか、新しい(けどテストの少ない)暫定バー ジョンを追いかけるか。安定したリリースは「cvs-1.10」のように小数点が1 つだけで、暫定リリースは "1.10.5" のように最後にマイナーバージョンをつ けてあってその数字が増えていきます。

GNU のサイトは通常メジャーリリースだけを提供して暫定のは提供しませんか ら、GNU のほうから CVS を取ってくる場合はこれら全部が見えるわけではあ りません。一般に、暫定リリースは大抵安全で、メジャーリリースで見つかっ たバグのバグフィクスが入っています。一番いいのは暫定リリースを追いかけ て、問題があったら必要なだけ前のリリースに戻すというやりかたです。さき ほどの例で一番新しい暫定リリースは cvs-1.10.6 です。ディレクトリに入ると

 
Index of /pub/cvs-1.10.6
    cvs-1.10.6.tar.gz      17-May-99 08:44   2.2M  

というのが見えます。これが CVS のソースコードです。これをダウンロード し、コンパイルします。GNU ツールのコンパイルに慣れていれば何をするかわ かるでしょうから、ここから A.6 Anatomy Of A CVS Distribution の節ま で飛ばしてもかまいません。慣れていなければ何をしていいかわからないでし ょうから、読みつづけて下さい…

ここからのコンパイル方法と例では、標準の Unix ディストリビューションを 前提にしています。フリーの Unix (FreeBSD や Linux) や、主な商業 Unix (SunOS/Solaris, AIX, HP-UX, Ultrix など)ならば問題ないと思います。もし 書いてある通りのやり方でうまくいかなくても諦めないで下さい。各 OS のコ ンパイルの詳しいところまではこの本の範囲ではありませんが、この章の最後 に参考になるリソースへのポインタを示します。

とにかくコンパイルを進めましょう、まず GNU gunzip と tar を使って tar ファイルをほどきます(これらがインストールされていない場合、gunzip は ftp://ftp.gnu.org/gnu/gzip/ で、GNU の tar は ftp://ftp.gnu.org/gnu/tar/ で手に入ります)。

 
floss$ gunzip cvs-1.10.6.tar.gz
floss$ tar xvf cvs-1.10.6.tar

スクリーン上をファイル名がたくさん流れるのが見えると思います。

これで新しいディレクトリ cvs-1.10.6 ができ、その中に CVS のコードがあ ります。ディレクトリの中に移り、そこにある configure スクリプトで CVS をそのシステム用に合わせましょう:

 
floss$ cd cvs-1.10.6
floss$  ./configure
creating cache ./config.cache
checking for gcc... gcc
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
  (etc) 

configure コマンドが終わると、ソースツリーはそのマシンでコンパイルする ために必要なことをすべて知っている状態になります。次はこうします:

 
floss$ make

出力がたくさん流れるのが見えると思います。その次はこうです:

 
floss$ make install

(最後のステップではスーパユーザになる必要があります) また出力が流れます、 これが終わると、CVS はマシンにインストールされています。

デフォルトでは CVS の実行ファイルは `/usr/local/bin/cvs' となりま す。それなりの make プログラムがシステムにインストールされていればの話 です(持っていなければ GNU プロジェクトの make を ftp://ftp.gnu.org/gnu/make/ から持っていって下さい)

CVS を /usr/local/bin 以外の場所にインストールしたければ、最初のコンフ ィギュレーションのやりかたを変えます。例えば

 
floss$ ./configure --prefix=/usr

とすると、CVS は /usr/bin/cvs としてインストールされます(PREFIX/bin/cvs になるわけです)。デフォルトの prefix は /usr/local になっていて、たい ていのインストールではこれでよいと思います。

今までのユーザのかたへ、以前のバージョンでは CVS は1つの実行ファイルに なっておらず、また、RCS がインストールされていることに依存していました が、バージョン 1.10 ではそうなっていません。ですから、cvs 以外のライブ ラリや実行ファイルのことを気にかけなくてもよくなりました。

リモートリポジトリにアクセスするためだけに CVS を使う場合は、ここまで でおしまいです。リポジトリを提供しようとしている場合には、ステップがあ といくつか残っています。この章のなかで、あとで説明します。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.5.2 Getting And Installing CVS Under Windows

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Getting%20And%20Installing%20CVS%20Under%20Windows"
"j-cvsbook/A.5.2GettingAndInstallingCVSUnderWindows"へのコメント(無し)
検索全文Elisp

ソースコードから実行ファイルを作ることについてこだわっているのでなけれ ば、 CVS を Windows 上でソースコードからコンパイルする必要はありません。 Unix とは違ってコンパイルツールがない場合が多いので、ソースから作ろう と思えばそのようなツールを持ってくることから始めなければならなくなりま す。そういうことはこの本の範囲ではありませんので、前もってコンパイルさ れた CVS バイナリをインストールする方法を教えます。

CVS の Windows バイナリディストリビューションは通常、メジャーリリース の分についてのみ作られることに注意して下さい、暫定リリースの分はありま せん。また、GNU FTP のほうには置いてありません。Cyclic Software のダウ ンロードサイトのメジャーバージョンディレクトリ http://download.cyclic.com/pub/cvs-1.10/ にアクセスしてください。 そうすると特別なサブディレクトリが見えます:

 
Index of /pub/cvs-1.10
    cvs-1.10.tar.gz        14-Aug-98 09:35   2.4M  
    windows/        

この中には ZIP ファイルがあります:

 
Index of /pub/cvs-1.10/windows
    cvs-1.10-win.zip       14-Aug-98 10:10   589k  

この ZIP ファイルは CVS のバイナリディストリビューションを含んでいます。 その ZIP ファイルをダウンロードしてほどいてください:

 
floss$ unzip cvs-1.10-win.zip

Archive:  cvs-1.10-win.zip
  inflating: cvs.html
  inflating: cvs.exe
  inflating: README
  inflating: FAQ
  inflating: NEWS
  inflating: patch.exe
  inflating: win32gnu.dll

README に詳しいインストール方法が書いてあります。インストールはだいた い次のような手順になります: EXE と DLL ファイルを PATH の通ったディレ クトリに置きます。リモートのリポジトリに pserver アクセスするつもりな ら `C:\AUTOEXEC.BAT' に次のように書いてください:

 
set HOME=C: 

これは .cvspass をどこに置くか指示するものです。そしてリブートします。

Windows 上で CVS を動かしても、現時点ではリモートのマシンにリポジトリ を提供できません。クライアントになれる(リモートのリポジトリに接続でき る)のと、ローカルモードで作業できる(同じマシンのリポジトリを使う)だけ です。この本では大部分で Windows で動く CVS はクライアントだと仮定して います。しかし、この章の残りの Unix 向けのところを読めば、Windows でロー カルリポジトリを設定することも難しくはありません。

リモートリポジトリにアクセスしているだけなら、CVS を走らせる必要さえあ りません。クライアントの機能を実装した WinCvs というツールがあります。 CVS そのものとは別に、それだけで配布されていますが、CVS と同様 GNU GPL ライセンス下で使用できます。詳しい情報は http://www.wincvs.org にてご覧ください。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.5.3 Getting And Installing CVS On A Macintosh

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Getting%20And%20Installing%20CVS%20On%20A%20Macintosh"
"j-cvsbook/A.5.3GettingAndInstallingCVSOnAMacintosh"へのコメント(無し)
検索全文Elisp

CVS は Macintosh でも利用できますが、メインのディストリビューションに は入っていません。今のところ、それぞれ異なる3つの Macintosh 用 CVS ク ライアントが存在します:

正直に言うと、どれが一番いいかわからないです。全部使ってみて(上の順番 通りに試す必要はありません)、いいと思うものを選んで下さい。MacCVS は WinCVS と同じホームページですし明らかに兄弟プロジェクトですね(これを書 いている今、WinCVS のページに「MacCvs の開発はまもなく再開されます」と いう意味のお知らせがあります)。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.5.4 Limitations Of The Windows And Macintosh Versions

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Limitations%20Of%20The%20Windows%20And%20Macintosh%20Versions"
"j-cvsbook/A.5.4LimitationsOfTheWindowsAndMacintoshVersions"へのコメント(無し)
検索全文Elisp

CVS の Windows 及び Macintosh ディストリビューションは機能に制限があり ます。これらはクライアントとしては動きます。つまりリポジトリサーバに接 続して作業コピーを取得し、コミット、アップデートなどを実行できます。し かしリポジトリを提供することはできません。正しく設定すれば Windows 用 のはローカルディスクリポジトリを使えますが、他のマシンへプロジェクトの リポジトリを提供することはできないのです。一般に、ネットワーク経由でア クセスできる CVS リポジトリを作りたい場合には Unix マシン上で CVS サー バを動かす必要があります。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.6 Anatomy Of A CVS Distribution

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Anatomy%20Of%20A%20CVS%20Distribution"
"j-cvsbook/A.6AnatomyOfACVSDistribution"へのコメント(無し)
検索全文Elisp

ここまで説明してきた方法は、とにかく始められるよう、早く動かすことが目 的でした。しかし、CVS のソースディストリビューションにはコードだけでな くいろいろ入っています。ここではソースツリーの早わかりロードマップをお 見せします。便利なものがいろいろあるので無視できないと思いますよ。

A.6.1 Informational Files  NEWS, BUGS, FAQ, etc.
A.6.2 Subdirectories  How the distribution is laid out.
A.6.3 The Cederqvist Manual  The CVS Online Manual.
A.6.4 Other Sources Of Information  Where else to find help.



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.6.1 Informational Files

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Informational%20Files"
"j-cvsbook/A.6.1InformationalFiles"へのコメント(無し)
検索全文Elisp

ディストリビューションツリーのトップレベルにファイルがいくつかあります が、これには有用な情報が書いてあります(あるいはより詳しい情報へのポイ ンタが書いてあります)。以下、重要な順に説明します:



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.6.2 Subdirectories

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Subdirectories"
"j-cvsbook/A.6.2Subdirectories"へのコメント(無し)
検索全文Elisp

CVS ディストリビューションにはたくさんのサブディレクトリがあります。通 常のインストールではその中を見たりしませんが、それぞれが何なのか知って おいても良いでしょう。

 
contrib/
diff/
doc/
emx/
lib/
man/
os2/
src/
tools/
vms/
windows-NT/
zlib/

大半は無視してかまいません。emx/, os2/, vms/, windows-NT/ には OS 依存 のコードがおさめてあって、CVS のコードレベルでデバッグするときくらいし か必要ないでしょう(あんまりありそうもない状況です、聞かないわけではな いですが)。diff/, zlib/ サブディレクトリはそれぞれ CVS の内部実装の diff プログラムとGNU gzip 圧縮ライブラリ部分です。(ネットワーク越しにリモー トリポジトリにアクセスする際にビット数を減らすため、後者を使っています)

contrib/, tools/ サブディレクトリに CVS とともに使用するフリーのサード パーティーソフトウェアをおさめてあります。contrib/ には特定の用途に専 門化された小さなシェルスクリプトの一群があります(contrib/README に何を するものか書いてあります)。tools/ サブディレクトリにはコントリビュート されたソフトウェアがあって、README にはこうあります:

 
以前このサブディレクトリには CVS とともに使用するツールがおさめてあり
ました。特に pcl-cvs バージョン1.xがおさめてありました。pcl-cvs は CVS 
の Emacs インタフェースです。

pcl-cvs をお探しの場合、こちらにある pcl-cvs バージョン2.xをお勧めします:

    ftp://ftp.weird.com/pub/local/

ここで述べられている PCL-CVS パッケージはとても使いやすいです、のちほ ど Third-Party Tools でもう少し説明します。

src/, lib/ サブディレクトリには CVS の内部を含むソースコード一式がおさ めてあります。主なデータ構造とコマンドの実装は src/ にあって、lib/ に は CVS が一般的に使用する小さなコードモジュールがあります。

man/ サブディレクトリに CVS の man page があります(Unix のオンラインマ ニュアルシステム用)。ここにある man page は make install を実行したと きにシステムの man page におさめられているので

 
floss$ man cvs

とタイプすると簡潔な紹介と CVS のサブコマンドのリファレンスが読めます。 これはクイックリファレンスとしては便利ですが、Cederqvist マニュアル(次 の節参照のこと)ほどには最新でもないし完璧でもありません。しかし間違っ ているわけではなくて不完全なだけですから、何かの足しになればと思います。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.6.3 The Cederqvist Manual

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20Cederqvist%20Manual"
"j-cvsbook/A.6.3TheCederqvistManual"へのコメント(無し)
検索全文Elisp

残りは doc/ サブディレクトリですが、このディレクトリの中の一番重要な住 人はあの有名な Cederqvist です。最近では "the Cederqvist" と呼ば れるようです。Per Cederqvist(Signum Support, Linkoping Sweden,www.signum.se) が 1992 年頃最初のバージョンを書き、それ以来たくさんの人々によって更新 されてきました。例えば、コントリビュータが新しい機能を CVS に追加したら、 Cederqvist にもドキュメントを残す、というかたちで。

Cederqvist マニュアルは GNU project でも使用されている Texinfo 形式で 書かれています。この形式にしておくと、オンライン出力もプリントアウト出 力も比較的容易に生成できるのです(それぞれ、Info と PostScript)。 doc/cvs.texinfo がマスタファイルですが、 CVS ディストリビューションには Info と PostScript 形式も入っていますから、自前で Texinfo ツールを走ら せる必要はありません。

Cederqvist は導入とチュートリアルとしても使用できますが、リファレンス ドキュメントとして使うのが一番便利です。そのため、多くの人はこれをプリ ントアウトせずにオンラインで閲覧しています(紙に印刷しておきたい人のた めに、PostScript ファイルは `doc/cvs.ps' です)。もし今回初めて CVS をインストールしたのなら、マニュアルにアクセスできるようにするために あとひと手間必要です。

Info ファイル (doc/cvs.info, doc/cvs.info-1, doc/cvs.info-2, など) は make install した時にインストールされました。しかしそれは Info ツリー にコピーされただけなので、Info の目次("Top" ノード)に1行追加する必要が あるのです。(これは最初にインストールした時だけ必要なことです、2回目以 降なら以前のインストールの時に追加したエントリがありますから)

もし今までに Info ドキュメントをシステムに追加したことがあるならこの手 順には慣れていると思います。まず Info ページがどこにインストールされて いるか探して下さい。デフォルトのインストールを使っていれば(/usr/local/)、 Info ファイルは /usr/local/info/cvs.info* です。次のようにインストール したのであれば

 
floss$ ./configure --prefix=/usr

Info ファイルは /usr/info/cvs.* になります。ファイルの場所が分かったら、 Info の目次に行を追加して下さい。そのディレクトリの dir という名前のフ ァイルです(後者の例では /usr/info/dir です)。root 権限がない場合はシス テム管理者にそれをしてくれるよう頼んで下さい。以下は CVS ドキュメント が追加される前の dir からの抜粋です:

 
* Bison: (bison).         The Bison parser generator. 
* Cpp: (cpp).             The GNU C preprocessor. 
* Flex: (flex).           A fast scanner generator

追加後の同じところは次の通り:

 
* Bison: (bison).         The Bison parser generator. 
* Cpp: (cpp).             The GNU C preprocessor. 
* Cvs: (cvs).             Concurrent Versions System
* Flex: (flex).           A fast scanner generator

追加する行の形式はとても重要です。`* Cvs:' にはアスタリスク、 スペース、コロンがあって、そのあとの `(cvs).' は括弧とピリオドが あります。どれが欠けても Info dif のフォーマットとして間違いで、Cederqvist が読めません。

マニュアルがインストールされ、目次から参照されるようになったら、Info 互換ブラウザで読めるようになります。典型的な Unix システムにインストー ルされているのは、以下のように起動すれば CVS のページへ直接行けるコマ ンドライン Info リーダか、

 
floss$ info cvs

Emacs 中で

 
M-x info 

あるいは

 
C-h i

とタイプすることによって起動されるものです。

CVS インストール時には、Cederqvist をきちんと読めるよう設定するために 時間を取って下さい。何度も調べる必要ができてくるのですから、その分の時 間の節約ができます。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.6.4 Other Sources Of Information

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Other%20Sources%20Of%20Information"
"j-cvsbook/A.6.4OtherSourcesOfInformation"へのコメント(無し)
検索全文Elisp

ディストリビューション中の Cederqvist, FAQ 他のファイルに加え、インター ネット上にも CVS に関するリソースがあります。CVS サーバを管理しようと している場合、info-cvs メーリングリストに参加したいなと思うかもしれま せん。購読するには、info-cvs-request@gnu.org にメールを送って 下さい(メーリングリスト本体は info-cvs@gnu.org です)。流量は 中から多量、1日に約20通程度で、大半が質問のメールです。たいがいは読ま ずに削除しても構わないですが(質問に回答する時は別です、素敵なことです ね)、時々、バグを発見したという報告や、ずっと欲しかった新しい機能を実 装するパッチのアナウンスがあるかもしれません。

正式なバグレポートメーリングリストに参加することもできます。ここにはバ グレポートがすべて送られます。バグをフィクスしたい人(素晴らしいことで すね)か、偏執狂気味で CVS について他の人が見つけた問題を全部知っておか ないと気が済まない人以外には必要ないと思います。参加したければ bug-cvs-request@gnu.org までメールを送って下さい。

Usenet ニュースグループもあります、comp.software.config-mgmt と いうものです。これはバージョン管理と設定管理一般のニュースグループで、 CVS についても少なからず議論されているようです。

最後に CVS 関連のウェブサイトを。少なくとも3つあります。ここ数年間、Cyclic Software の http://www.cyclic.com は CVS の非公式なホームサイト であり、多分近い未来についてもそうでありつづけると思います。Cyclic Software はサーバスペースと、CVS のソースが入ったリポジトリのネットワークアクセ スを提供しています。また、Cyclic のウェブページには広範囲にわたるリン クがあります。CVS の実験的パッチあり、CVS とともに使用するサードパーテ ィーツールあり、ドキュメントやメーリングリストアーカイブあり。他にもい ろいろあります。分散したリソースの中で、必要なものが見つからない時は、 http://www.cyclic.com から見始めるのがよいでしょう。

ステキなサイトをあと2つ紹介しましょう。Pascal Molli の http://www.loria.fr/~molli/cvs-index.html と、Sean Dreilinger の http://durak.org/cvswebsites/ です。Molli のサイトの一番の目玉 はもちろん FAQ ですが、CVS 関連ツールへのリンクや、メーリングリストの アーカイブなどもあります。Dreilinger のサイトはウェブドキュメントを管 理する場合の CVS の使い方の情報に詳しく、また、CVS に特化したサーチエ ンジンがあります。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.7 Starting A Repository

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Starting%20A%20Repository"
"j-cvsbook/A.7StartingARepository"へのコメント(無し)
検索全文Elisp

CVS の実行ファイルがシステムにインストールできたら、まずは An Overview of CVS に従って、リモートリポジトリにアクセスするク ライアントとして使ってみましょう。しかし、自分のマシンからリビジョンを 提供したいのであれば、そこにリポジトリをつくらねばなりません。それを実 現するコマンドは以下のとおり、

 
floss$ cvs -d /usr/local/newrepos init

`/usr/local/newrepos' はリポジトリになって欲しいディレクトリへの パスです(当然そこへ書込める権限がなければなりません、コマンドを root 権限で実行しても構いません)。init サブコマンドの後ではなく、前に新しい リポジトリの場所を指定するのは直感に反するような気がするかもしれません が、-d オプションの使い方に関して言えば、他の CVS コマンドと一貫してい ます。

このコマンドを走らせると、黙って終わります。新しいディレクトリを調べて みましょう:

 
floss$ ls -ld /usr/local/newrepos
drwxrwxr-x   3 root     root         1024 Jun 19 17:59 /usr/local/newrepos/
floss$ cd /usr/local/newrepos
floss$ ls
CVSROOT
floss$ cd CVSROOT
floss$ ls
checkoutlist     config,v        history     notify     taginfo,v
checkoutlist,v   cvswrappers     loginfo     notify,v   verifymsg
commitinfo       cvswrappers,v   loginfo,v   rcsinfo    verifymsg,v
commitinfo,v     editinfo        modules     rcsinfo,v
config           editinfo,v      modules,v   taginfo

floss$ 

新しいディレクトリにはサブディレクトリがひとつだけあり(CVSROOT/)、CVS の動作をコントロールするいろいろな管理ファイルがおさまっています。今後、 これらのファイルをひとつひとつ見ていく予定です。今のところはリポジトリ がちゃんと動くことが目標です。ここで「ちゃんと動く」とは、ユーザがプロ ジェクトをインポート、チェックアウト、アップデート、コミットできるとい う意味です。

An Overview of CVS で述べた CVSROOT 環境変数と、リポジトリの中に あるこの CVSROOT サブディレクトリを混同しないように。全然関係ないです。 不運にも偶然一致してしまい、同じ名前がついているだけです。前者は、CVS を使うときにいちいち `-d <repository-location>' とタイプする のがイヤなユーザ向けのもので、後者はリポジトリの管理用サブディレクトリ です。

リポジトリが作成できたら、そのパーミッションに注意して下さい。CVS は特 別な統一されたパーミッションやファイルの所有権の計画(?)は要求しません。 リポジトリへ書き込める権限が必要なだけです。しかし、一部セキュリティー 上の理由ですがどちらかというと主に管理者のまっとうな分別として、次の手 順を踏むことを強く推奨します。

  1. システムに cvs というグループを追加し、リポジトリにアクセスする 必要のあるユーザはそのグループに加えます。例として筆者のマシンの `/etc/group' ファイルの関連する行をお見せしましょう:

     
    cvs:*:105:kfogel,sussman,jimb,noel,lefty,fitz,craig,anonymous,jrandom
    

  2. リポジトリのオーナグループとグループパーミッションを変えて、そのグルー プを反映するようにします:

     
    floss$ cd /usr/local/newrepos
    floss$ chgrp -R cvs .
    floss$ chmod ug+rwx . CVSROOT
    

これで、グループにいるユーザは誰でも cvs import を実行すれ ば(このへんのことは An Overview of CVS に説明があります)プロジェ クトを始めることができるようになりました。checkout, update, commit も 同様に動きます。リポジトリマシンに rsh または sh アクセスができるなら、 :ext: を使ってリモートからアクセスすることもできます。( 上の例の chgrp と chmod コマンドだと、誰だかもわからない anonymous ユーザに書込み権限を与えてしまうことにお気づきでしょうか。こうしている 理由は、リポジトリを読むだけの anonymous ユーザであろうとも、CVS プロ セスがリポジトリ内に一時ロックファイルを作れるようにしておかなければな らないので、システムレベルでの書込み権限が必要だからなのです。CVS は read-only 制限を実現するのに Unix ファイルシステムの権限は使っておらず、 別の方法を使っているのです。これについては A.9 Anonymous Access で述 べます。)

コントリビュータがリポジトリマシン上のアカウントを持つ必要がないような プロジェクトを一般に公開するリポジトリの場合は、パスワード認証サーバを 設定するべきです(see 節 A.8 The Password-Authenticating Server)。これは匿 名の読み出し専用アクセスに必要ですし、マシンのフルアカウントを与えるこ となしに特定の人々にコミットアクセスを許可する一番簡単な方法でもありま す。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.8 The Password-Authenticating Server

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20Password-Authenticating%20Server"
"j-cvsbook/A.8ThePassword-AuthenticatingServer"へのコメント(無し)
検索全文Elisp

パスワードサーバのセットアップに必要な手順を実行する前に、このような接 続がどのように動いているのか大雑把に見ておきましょう。リモートの CVS クライアントが :pserver: メソッドを使ってリポジトリに接続すると き、クライアントは実際にはサーバマシンの特定のポート番号、明確に言うと 2401 番(49の2乗と言ってもいいです、そういうのがお好きなら)に接続しに行き ます。2401番ポートは CVS pserver 用に指定されたデフォルトポートですが、 クライアントとサーバの共通了解さえあれば別のポートに設定することも可能 です。

CVS サーバはそのポートで接続をずっと待っているわけではなく、実際に接続 要求があるまで起動されません。かわりに Unix の inted (InterNET Daemon) プログラムがそのポートを listen しています。接続要求を受け取ったときに どうするかを教えておく必要がありますが、そうすると inetd が CVS サーバ を起動して、入って来たクライアントと接続してくれます。

これを実現するには inetd の設定ファイル、`/etc/services' と `/etc/inetd.conf' を変更します。services ファイルは生のポート番号とサー ビス名を対応づけ、inetd.conf には inetd が各サービス名に対して何をすれ ばよいかを書いてあります。

まず /etc/services に次の1行を追加して下さい(この行がファイルにないこ とを確認してからですよ)

 
cvspserver	2401/tcp

次に /etc/inetd.conf にこれを追加してください:

 
cvspserver stream tcp nowait root /usr/local/bin/cvs cvs \
   --allow-root=/usr/local/newrepos pserver

(上記は実際のファイルではバックスラッシュなしの1つの長い行にしてくださ い) ただし、tcpwrapper が導入されたシステムにおいては次のようにしてく ださい:

 
cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/local/bin/cvs \
   --allow-root=/usr/local/newrepos pserver

inetd を再起動して、設定ファイルの変更を反映して下さい。(inetd の再起 動の仕方を知らない場合はマシンをリブートしてください、それで動くように なります)

接続を許可するためにはこれだけでいいのですが、ユーザの通常のログインパ スワードとは別に、CVS 用のパスワードを設定したいでしょう。そうすればシ ステム全体のセキュリティについて妥協することなくリポジトリにアクセスさ せることができるようになります。

リポジトリ内の CVSROOT/passwd が CVS のパスワードファイルです。このフ ァイルは cvs init を実行したときにデフォルトで生成されたりはしません。 CVS を pserver で提供するとは限らないからです。パスワードファイルが生 成されたとしても、CVS ではユーザ名とパスワードを生成できません。自分で 作る必要があります。CVSROOT/passwd ファイルのサンプルを示します:

 
kfogel:rKa5jzULzmhOo
anonymous:XR4EZcEs0szik
melissa:tGX1fS8sun6rY:pubcvs

フォーマットはご覧の通りごく簡単です。各行次のようにしてください:

 
<USERNAME>:<ENCRYPTED_PASSWORD>:<OPTIONAL_SYSTEM_USERNAME>

余分にコロンとオプショナルシステムユーザ名をつけると、CVS は USERNAME として認証した接続を SYSTEM_USERNAME というシステムアカウントの権限で 実行します。言い換えると そのセッションでは SYSTEM_USERNAME としてログ インしたときと同様のことがリポジトリ内で実行できる、ということです。

システムユーザ名が指定されていない場合、USERNAME はシステム上に実際に 存在するログインアカウントと一致しなければならず、セッションはそのユー ザの権限で実行されます。どちらの場合でも、ENCRYPTED_PASSWORD はシステ ムの実際のログインパスワードと一致しなくても構いません。それは CVS の pserver 接続にのみ用いられる、他と関係ないパスワードです。

パスワードは /etc/passwd にパスワードを保存するときに使われているのと 同じアルゴリズムで暗号化されます。ここで「どうやって暗号化したパスワー ドを持ってくればいいの?」という疑問が出てきます。Unix のシステムパスワー ドなら、passwd コマンドが /etc/passwd の暗号化を面倒見てくれます。しか し、それに対応するような cvs passwd コマンドはありません(これは何度か 提案されていますが、まだ誰も書いていないんですよ。あなたがやってくれま すか?)。

不便でしょうもない方法がひとつあります。他にどうしようもなければ、通常 のシステムパスワードを passwd コマンドで変えて、暗号化されたものを /etc/passwd から CVSROOT/passwd へカットアンドペーストし、元のパスワード に戻す、というのでなんとかなります(暗号化されたパスワードが /etc/shadows にあって、root 権限がないと読めない場合もあります)。

この方法はしかしかなり厄介です。暗号化されていないパスワードを引数で渡 せば暗号化されたものを出力してくれるような、コマンドラインユーティリテ ィを作るほうが簡単でしょう。Perl で書いたそういうツールをお見せしまし ょう:

 
#!/usr/bin/perl

srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter); 
my $plaintext = shift; 
my $crypttext = crypt ($plaintext, $salt); 

print "${crypttext}\n";

わたしはこのスクリプトを `/usr/local/bin/cryptout.pl' に置いてい ます。

 
floss$ ls -l /usr/local/bin/cryptout.pl 

-rwxr-xr-x   1   root   root   265  Jun 14 20:41 /usr/local/bin/cryptout.pl
floss$ cryptout.pl "some text"
sB3A79YDX5L4s

floss$ 

この例の出力を CVSROOT/passwd のエントリ作成に使ったとします:

 
jrandom:sB3A79YDX5L4s:craig

で、誰かが次のコマンドを使ってリポジトリに接続するとすると:

 
remote$ cvs -d :pserver:jrandom@floss.red-bean.com:/usr/local/newrepos login

ここでパスワードに some text とタイプすれば、以降は craig のアクセス権限で CVS コマンドを実行することができます。

CVSROOT/passwd にないユーザ名とパスワードでログインしようとした場合、 CVS は /etc/passwd のユーザ名とパスワードをチェックします。もし存在す れば(そして当然ですがパスワードが一致すれば)、CVS はアクセスを許可しま す。この振舞いは管理者の便宜のため、つまり通常のシステムユーザの分まで いちいち CVSROOT/passwd のエントリを設定しなくてもよいようにするための ものです。しかしこれはセキュリティホールにもなります。なぜなら、そのよ うなユーザが CVS に接続しようとすると、通常のログインパスワードが暗号 化されずにネットワーク上に流れてしまい、パスワード盗み屋に見られてしま うかもしれないからです。このあとでこの「fallback」な振舞いを無効にする 方法を述べます。有効にするにしろ無効にするにしろ、ログインアカウントも 持っている CVS ユーザに対しては、それぞれを違うパスワードにするように、 おそらく強制すべきです。

passwd ファイルでの認証はリポジトリ全体に対して有効なのですが、少し工 夫すればプロジェクトごとのアクセス許可を設定するために使用することもで きます。一方法を示します:

次のように仮定します。リモートの開発者にプロジェクト foo へのア クセスを許可し、また別のリモートの開発者にプロジェクト bar への アクセスを許可するが、一方のプロジェクトの開発者には、もう一方のプロジ ェクトにコミットさせたくない。この場合、プロジェクト別のユーザアカウン トとグループをシステム上に作成し、CVSROOT/passwd ファイルで対応させる ことによって実現できます。

/etc/passwd から関連部分の抜粋:

 
cvs-foo:*:600:600:Public CVS Account for Project Foo:/usr/local/cvs:/bin/false
cvs-bar:*:601:601:Public CVS Account for Project Bar:/usr/local/cvs:/bin/false

/etc/group からの抜粋:

 
cvs-foo:*:600:cvs-foo
cvs-bar:*:601:cvs-bar

最後に CVSROOT/passwd からの抜粋です:

 
kcunderh:rKa5jzULzmhOo:cvs-foo
jmankoff:tGX1fS8sun6rY:cvs-foo
brebard:cAXVPNZN6uFH2:cvs-foo
xwang:qp5lsf7nzRzfs:cvs-foo
dstone:JDNNF6HeX/yLw:cvs-bar
twp:glUHEM8KhcbO6:cvs-bar
ffranklin:cG6/6yXbS9BHI:cvs-bar
yyang:YoEqcCeCUq1vQ:cvs-bar

CVS ユーザ名のうちいくつかはシステムユーザアカウント cvs-foo と 対応しており、いくつかは cvs-bar に対応しています。CVS はシステ ムアカウントのユーザIDの権限で動作しますので、リポジトリのうち関連する 部分には適切なユーザとグループの書込み権限を与えておいて下さい。ユーザ アカウントをきちんとロックしておけば(ログインパスワードを無効にし、シ ェルには `/bin/false' を設定)、このシステムは十分セキュアです(こ の章で後ほど述べる CVSROOT のパーミッションについて読んでおいて下さい ね!)。また、CVS ではレコードやログメッセージの変更をシステムユーザ名で はなく CVS ユーザ名で行うので、ある変更が誰の責任なのかというのもわか ります。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.9 Anonymous Access

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Anonymous%20Access"
"j-cvsbook/A.9AnonymousAccess"へのコメント(無し)
検索全文Elisp

ここまでパスワード認証サーバを使って、リポジトリに対し通常のフルアクセ スを許可するやりかたを見てきました(Unix ファイルパーミッションを巧みに 利用してアクセス制限をすることは可能ですが)。一方、匿名の読み出し専用 アクセスを実現するにはワンステップで済みます: CVSROOT/ の下に新しいフ ァイルを1つか、もしかしたら2つ、追加するだけでいいのです。ファイル名は readerswriters、前者はリポジトリを読めるユーザ名の、 後者は読み書きできるユーザ名のリストです。

CVSROOT/readers にユーザ名を書くと、そのユーザはリポジトリ内の全てのプ ロジェクトに対する読み出しアクセスのみ可能になります。CVSROOT/writers にユーザ名を書くと、そのユーザは書込み権限を得、writers ファイルに書か れていない他の pserver ユーザは読み出しアクセスのみ可能になります(つま り、writers ファイルが存在するということは、そこに書かれていないユーザ を読み出しアクセスのみに制限するという意味になります)。両方のファイル に同じユーザ名が書かれている場合、CVS はその矛盾を保守的な方法で解決し ます: そのユーザは読み出しアクセスのみ可能になります。

ファイルの形式は非常に単純で、各行1ユーザです(最後のユーザの後に改行を 入れるのを忘れないで)。readers ファイルのサンプルを示します:

 
anonymous
splotnik
guest
jbrowse

それらのファイルは CVS ユーザ名に適用されます。システムユーザ名ではあ りません。CVSROOT/passwd のユーザエイリアス機能を使っている場合(2番目 のコロンの後にシステムユーザ名を書いている場合)、readers または writers ファイルに使用するのは一番左側のユーザ名です。

Just to be painfully accurate about it, 許可するのが読み出しアクセスか 読み書きアクセスかを決定する時のサーバの動作を正式に説明するとこうなり ます:

readers ファイルが存在し、その中にそのユーザが書いてあれば、読み出しア クセス。writers ファイルが存在し、その中にそのユーザがなければ、読み出 しアクセス(これは readers ファイルが存在していてそのユーザがその中にな い場合にも真)。そのユーザが両方に書いてあれば、読み出しアクセス。その 他の場合、読み書きアクセス。

従って、典型的な匿名 CVS アクセスのリポジトリは CVSROOT/passwd には次 のような行があります

 
anonymous:XR4EZcEs0szik

/etc/passwd には次のような行

 
anonymous:!:1729:105:Anonymous CVS User:/usr/local/newrepos:/bin/false

CVSROOT/readers には次のような行

 
anonymous

当然 /etc/services と /etc/inetd.conf には以前言ったような設定を。これ で全部です。

古めの Unix システムでは8文字以上のユーザ名をサポートしていないことに 注意して下さい。これに対応するひとつの方法は、CVSROOT/passwd ファイル とシステムファイルでそのユーザを anonymous ではなく anon にしておくことです。anonymous の短縮形は anon だろう、と思う人は多いで すから。しかし、 CVSROOT/passwd ファイルにこのような行を書くほうがよい かもしれません:

 
anonymous:XR4EZcEs0szik:cvsanon

(もちろんシステムファイルでは cvsanon を使って下さい)。こうすれ ば、多少標準的な anonymous を使ったリポジトリアドレスを公開でき ます。リポジトリに

 
cvs -d :pserver:anonymous@cvs.foobar.com:/usr/local/newrepos (etc...)

でアクセスしてくる人は、サーバ上では cvsanon (かなんか)の権限で実行さ れますが、その人たちはサーバ側でどう設定されているかなんて知る必要はな く、ただ公開されたアドレスだけ見ていればいいのです。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.10 Repository Structure

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Repository%20Structure"
"j-cvsbook/A.10RepositoryStructure"へのコメント(無し)
検索全文Elisp

新しく作られたリポジトリにはプロジェクトはありません。An Overview of CVS の最初のインポートのところからやりなおして、リポジトリに何が起 こるかを見ていきましょう。(単純のため、全てのコマンドで CVSROOT 環境変 数が /usr/local/newrepos が設定されていると仮定します、インポートやチ ェックアウトの際 -d でリポジトリを指定しなくてもいいように)

 
floss$ ls /usr/local/newrepos
CVSROOT/
floss$ pwd
/home/jrandom/src/
floss$ ls
myproj/
floss$ cd myproj
floss$ cvs import -m "initial import into CVS" myproj jrandom start
N myproj/README.txt
N myproj/hello.c
cvs import: Importing /usr/local/newrepos/myproj/a-subdir
N myproj/a-subdir/whatever.c
cvs import: Importing /usr/local/newrepos/myproj/a-subdir/subsubdir
N myproj/a-subdir/subsubdir/fish.c
cvs import: Importing /usr/local/newrepos/myproj/b-subdir
N myproj/b-subdir/random.c

No conflicts created by this import

floss$ ls /usr/local/newrepos
CVSROOT/  myproj/
floss$ cd /usr/local/newrepos/myproj
floss$ ls
README.txt,v  a-subdir/     b-subdir/	  hello.c,v
floss$ cd a-subdir
floss$ ls
subsubdir/    whatever.c,v
floss$ cd .. 

floss$ 

インポート前、リポジトリ内には管理領域しかありません。インポート後、新 しいディレクトリ(`myproj')が出現しています。新しいディレクトリの 中のファイルとサブディレクトリはインポートしたプロジェクトに見えなくは ないですが、なんだかファイル名に ,v というサフィックスがついて います。これらは RCS 形式のバージョン管理ファイルで(,v は "version" という意味です)、リポジトリの大黒柱になるものです。各 RCS ファイルはプ ロジェクト内の対応するファイルの、ブランチやタグも含めたリビジョン履歴 を保持しています。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.11 RCS Format

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=RCS%20Format"
"j-cvsbook/A.11RCSFormat"へのコメント(無し)
検索全文Elisp

CVS を使うにあたり、RCS 形式について知っておく必要は一切ありません(ソー スディストリビューションに素晴らしい記事がありますけれど。doc/RCSFILES をご覧ください)。しかし、この形式の基本的なところを理解していると CVS のトラブルシューティングに非常に役に立ちますので、ファイルの1つ ` hello.c,v' をちょっと覗いてみることにしましょう。ファイル内容を示します:

 
head     1.1; 
branch   1.1.1; 
access   ; 
symbols  start:1.1.1.1 jrandom:1.1.1; 
locks    ; strict; 
comment  @ * @;

1.1
date     99.06.20.17.47.26;  author jrandom;  state Exp; 
branches 1.1.1.1; 
next; 

1.1.1.1
date     99.06.20.17.47.26;  author jrandom;  state Exp; 
branches ; 
next; 

desc
@@

1.1
log
@Initial revision
@
text
@#include <stdio.h>

void
main ()
{
  printf ("Hello, world!\n");
}
@

1.1.1.1
log
@initial import into CVS
@
text
@@

うひゃー! もうほとんど無視してもかまわないです; 例えば 1.1 と 1.1.1.1 の関連や、暗黙の 1.1.1 ブランチとかは気にしないで下さい、ユーザ、管理 者、どちらの観点からもあまり重要なことではありません。理解すべきは全体 のフォーマットです。最初はヘッダフィールドのコレクションです:

 
head     1.1; 
branch   1.1.1; 
access   ; 
symbols  start:1.1.1.1 jrandom:1.1.1; 
locks    ; strict; 
comment  @ * @;

そのあとは各リビジョンのメタ情報のグループです(リビジョンの中身はまだ 先です)、こんな感じ:

 
1.1
date     99.06.20.17.47.26;  author jrandom;  state Exp; 
branches 1.1.1.1; 
next     ; 

最後にログメッセージと実際のリビジョンのテキストが来ます:

 
1.1
log
@Initial revision
@
text
@#include <stdio.h>

void
main ()
{
  printf ("Hello, world!\n");
}
@

1.1.1.1
log
@initial import into CVS
@
text
@@

よくみると、最初のリビジョンの内容が 1.1 という見出しの下にあって、そ のログメッセージがなぜか "Initial revision" になっています。インポート 時に使ったのは "initial import into CVS" というログメッセージなのに。 そっちのログメッセージはもっと下のほう、Revision 1.1.1.1 の下に あります。今この矛盾を気にする必要はありません。これはインポートが特別 な場合だから起こることなのです。It happens because imports are a special circumstance: Inorder to make repeated imports into the same project have a usefuleffect, import actually places the initial revision on both the maintrunk and on a special branch (これの理由は Advanced CVS でベンダブランチについて述べるときにもう少し明らかになります). 今のと ころは 1.11.1.1.1 を同じものとして扱っても構いません。

hello.c の最初の変更をコミットすると、このファイルのことがもう少しわか ってきます:

 
floss$ cvs -Q co myproj
floss$ cd myproj
floss$ emacs hello.c
    (ファイルを変更してみる) 

floss$ cvs ci -m "print goodbye too"
cvs commit: Examining . 
cvs commit: Examining a-subdir
cvs commit: Examining a-subdir/subsubdir
cvs commit: Examining b-subdir
Checking in hello.c; 
/usr/local/newrepos/myproj/hello.c,v  <--  hello.c
new revision: 1.2; previous revision: 1.1
done

ここでリポジトリ内の hello.c,v を見ると、コミットの結果がわかります:

 
head  1.2; 
access; 
symbols
      start:1.1.1.1 jrandom:1.1.1; 
locks; strict; 
comment   @ * @;

1.2
date   99.06.21.01.49.40;   author jrandom;   state Exp; 
branches; 
next   1.1; 

1.1
date   99.06.20.17.47.26;   author jrandom;   state Exp; 
branches
       1.1.1.1; 
next   ; 

1.1.1.1
date   99.06.20.17.47.26;   author jrandom;   state Exp; 
branches; 
next   ; 

desc
@@

1.2
log
@print goodbye too
@
text
@#include <stdio.h>

void
main ()
{
  printf ("Hello, world!\n");
  printf ("Goodbye, world!\n");
}
@

1.1
log
@Initial revision
@
text
@d7 1
@

1.1.1.1
log
@initial import into CVS
@
text
@@

リビジョン1.2全体の内容がファイルに保存されており、リビジョン1.1の内容 は暗号ちっくな形式に置き換わっています:

 
d7 1

d7 1 は「7行目から始めて、1行削除する」という意味の diff コー ドです。言い換えると、リビジョン1.1を導出するにはリビジョン1.2から7行 目を削除する、ということなのです! 自分で実際にやってみてください。これ でリビジョン1.1ができるのがわかると思います。単純に、ファイルに追加し た行をなくすだけです。

これは RCS 形式の基本原則を示しています: リビジョン間の相違のみを保存 し、そうすることによって各リビジョンそれぞれの全体を保存するのに比べて 容量を節約します。一番新しいリビジョンから以前のリビジョンへ戻るには、 保存してある diff をより最近のリビジョンに対して patch すればよろしい。 つまりこれは、過去に戻ろうとすればするほど、より多くの patch 操作が必 要になる、ということです(たとえばリビジョン1.7のファイルがあって、その ファイルのリビジョン1.4へのアクセスを要求された場合、patch で 1.7 から 1.6 を生成し、1.6 から 1.5 を、そして 1.5 から 1.4 を生成します)。幸い、 古いリビジョンはあまりアクセスされませんので、実用上 RCS システムはう まく動きます。最近のファイルになるほど取得するコストが低いわけです。

ファイルの冒頭のヘッダ情報が何を意味するか、全てを理解する必要はありませ ん。しかし、ある種の操作は、結果がとても明確にヘッダに示されますので、ヘッ ダに親しんでおくと便利には違いありません。

トランクに新しいリビジョンをコミットした時、head ラベルが更新され ます(先に示した例で、2回目に hello.c をコミットした時、そのラベルがどの ように 1.2 になったか注意して見てみてください)。あるファイルをバイナリと して追加した時、あるいはタグをつけた時にも、それらの操作はヘッダに記録さ れます。例として foo.jpg をバイナリファイルとして追加し、その後二度ほど タグづけしてみましょう:

 
floss$ cvs add -kb foo.jpg
cvs add: scheduling file 'foo.jpg' for addition
cvs add: use 'cvs commit' to add this file permanently
floss$ cvs -q commit -m "added a random image; ask jrandom@red-bean.com why"
RCS file: /usr/local/newrepos/myproj/foo.jpg,v
done
Checking in foo.jpg; 
/usr/local/newrepos/myproj/foo.jpg,v  <--  foo.jpg
initial revision: 1.1
done
floss$ cvs tag some_random_tag foo.jpg
T foo.jpg
floss$ cvs tag ANOTHER-TAG foo.jpg
T foo.jpg
floss$ 

さて、リポジトリ内の foo.jpg,v のヘッダ部分を見てみましょう:

 
head   1.1; 
access; 
symbols
      ANOTHER-TAG:1.1
      some_random_tag:1.1; 
locks; strict; 
comment   @# @;
expand	@b@;

最後の expand の行の b を見て下さい。これはこのファイルを -kb つきで add したためにこうなっています。通常のテキストファイルでは、チェックアウトと アップデートの時にキーワードや改行コードの変換が行われるのですが、このファ イルではそれが行われない、という意味です。タグは symbols セクションに 1 タグ1行で記してあります。最初のリビジョンに2回タグをつけたので、タグは両 方とも最初のリビジョンについています。(タグ名に英数字、ハイフン、アンダ スコアしか使えない理由もこれで説明できます。タグがコロンやピリオドを含ん でいたとしたら、RCS ファイルのこの欄のタグとリビジョンの区切りが曖昧になっ てしまうからですね。)

RCS Format Always Quotes @ Signs

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=RCS%20Format%20Always%20Quotes%20@%20Signs"
"j-cvsbook/RCSFormatAlwaysQuotes@Signs"へのコメント(無し)
検索全文Elisp

RCS ファイル中の @ シンボルはフィールド(訳注: フィールドとは各リ ビジョンの領域のことのようです)の区切りに使用されますので、ファイルのテ キスト中やログメッセージに出てくる場合にはクオートする必要があります(そ うしないと CVS はそれをフィールドの最後だと誤解してしまいます)。クオート するには を2つ続けます。つまり、CVS は @@ が出てくると、フィー ルドの終わりという意味ではなく、@ 記号であると解釈します。foo.jpg をコ ミットしたときのログメッセージは

 
"added a random image; ask jrandom@red-bean.com why"

でした、これは foo.jpg,v 中ではこのようになります:

 
1.1
log
@added a random image; ask jrandom@@red-bean.com why
@

ログメッセージにアクセスするときにはj random@@red-bean.com の中の @ 記号は自動的にクオートがはずされます:

 
floss$ cvs log foo.jpg
RCS file: /usr/local/newrepos/myproj/foo.jpg,v
Working file: foo.jpg
head: 1.1
branch: 
locks: strict
access list: 
symbolic names: 
      ANOTHER-TAG: 1.1
      some_random_tag: 1.1
keyword substitution: b
total revisions: 1;	selected revisions: 1
description: 
----------------------------
revision 1.1
date: 1999/06/21 02:56:18;  author: jrandom;  state: Exp; 
added a random image; ask jrandom@red-bean.com why
============================================================================

floss$ 

RCS ファイルを手で編集する時くらいしか気にすることはないです(ほとんどな いとは思いますが、全然ないわけではありません)。その場合はリビジョン内容 とログメッセージで 記号を2つ重ねて書くことを思い出してください。もし忘 れたら、RCS ファイルはむちゃくちゃになり、思いもかけないヘンな動作をする でしょう。

Speaking of hand-editing RCS files, don't be fooled by the permissions in the repository:

 
floss$ ls -l
total 6
-r--r--r--   1 jrandom   users         410 Jun 20 12:47 README.txt,v
drwxrwxr-x   3 jrandom   users        1024 Jun 20 21:56 a-subdir/
drwxrwxr-x   2 jrandom   users        1024 Jun 20 21:56 b-subdir/
-r--r--r--   1 jrandom   users         937 Jun 20 21:56 foo.jpg,v
-r--r--r--   1 jrandom   users         564 Jun 20 21:11 hello.c,v

floss$ 

(Unix の ls の出力に詳しくない人へ、左のほうの -r--r--r-- は、そ のファイルは読めるけど変更できないよ、という意味です) これらのファイルは 誰に対してもリードオンリーのように見えますが、ディレクトリパーミッション のほうを考慮に入れなくてはなりません:

 
floss$ ls -ld . 
drwxrwxr-x   4 jrandom   users        1024 Jun 20 22:16 ./ 
floss$

myproj/ 自身とそのサブディレクトリは、オーナ(jrandom)とグループ(users)の 書き込み権限があります。これはつまり、(jrandom 及び users グループの メンバーなら誰でも、の権限で実行される) CVS はそれらのディレクトリでファ イルを作ったり削除したりできるということです、既に存在するファイルを直接 編集することができないとしても。CVS は RCS ファイルのコピーを取って編集 するので、あなたも一時コピーを好きなように変更し、既存の RCS ファイルを その新しいファイルで置き換えたっていいのです。(なんでファイルがリードオ ンリーなのかというのは聞かないでください、RCS がスタンドアロンで動く時の 動作のしかたに関係のある歴史的経緯があるのです)

ついでに言うと、リポジトリのトップレベルディレクトリのグループが cvs であることを考えれば、それらのファイルのグループが users になっているのは望ましいことではないと思います。リポジトリ 内でこのコマンドを実行すれば問題を解決できます:

 
floss$ cd /usr/local/newrepos
floss$ chgrp -R cvs myproj

リポジトリ内に新しく作成されるファイルのグループについては、Unix の通常 のファイル作成時のルールが適用されてしまうので、たまにリポジトリ内のファ イルやディレクトリを chgrp または chmod してやる必要があると思います。 リポジトリのパーミッションをどう構成するかについて、難しい固定した規則 はありません、単にどのプロジェクトで誰が作業しているかによります。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.12 What Happens When You Remove A File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=What%20Happens%20When%20You%20Remove%20A%20File"
"j-cvsbook/A.12WhatHappensWhenYouRemoveAFile"へのコメント(無し)
検索全文Elisp

あるプロジェクトからファイルを削除する場合、そのファイルは単になくなる だけではありません。 プロジェクトの古いスナップショットを要求されても、 CVS はそのようなファイルにもちゃんとアクセスできなければならないのです。 なくなるかわりに、そのファイルは文字通り Attic(訳注: Attic=屋根 裏)に移されます:

 
floss$ pwd
/home/jrandom/src/myproj
floss$ ls /usr/local/newrepos/myproj/
README.txt,v  a-subdir/     b-subdir/     foo.jpg,v   hello.c,v
floss$ rm foo.jpg
floss$ cvs rm foo.jpg
cvs remove: scheduling 'foo.jpg' for removal
cvs remove: use 'cvs commit' to remove this file permanently
floss$ cvs ci -m "Removed foo.jpg" foo.jpg
Removing foo.jpg; 
/usr/local/newrepos/myproj/foo.jpg,v  <--  foo.jpg
new revision: delete; previous revision: 1.1
done
floss$ cd /usr/local/newrepos/myproj/
floss$ ls
Attic/      README.txt,v  a-subdir/     b-subdir/   hello.c,v
floss$ cd Attic
floss$ ls
foo.jpg,v
floss$

プロジェクトのリポジトリ内ディレクトリに `Attic/' というサブディレ クトリがある場合、それは、少なくとも1ファイルはそのディレクトリから削除 された、ということを意味します(つまりプロジェクトで Attic という名前の ディレクトリは使ってはいけないということです)。CVS は RCS ファイルを Attic/ に移すだけではなく、そのファイルの新しいリビジョンを、 dead という特別なリビジョン状態でコミットします。Attic/foo.jpg,v から関係個所を示します:

 
1.2
date   99.06.21.03.38.07;   author jrandom;   state dead; 
branches; 
next	1.1; 

あとでファイルを生き返らせた場合CVS は、過去のある時点でこのファイルが 死に、今は再び生きている、ということを記録します。

これはつまり、削除したファイルを元に戻したい場合に Attic/ ディレクトリ から出してプロジェクトに戻しただけではダメだということを意味します。そ うではなくて、作業コピー内で次のようにしてください:

 
floss$ pwd
/home/jrandom/src/myproj
floss$ cvs -Q update -p -r 1.1 foo.jpg > foo.jpg
floss$ ls
CVS/       README.txt   a-subdir/   b-subdir/   foo.jpg     hello.c
floss$ cvs add -kb foo.jpg
cvs add: re-adding file foo.jpg (in place of dead revision 1.2) 
cvs add: use 'cvs commit' to add this file permanently
floss$ cvs ci -m "revived jpg image" foo.jpg
Checking in foo.jpg; 
/usr/local/newrepos/myproj/foo.jpg,v  <-- foo.jpg
new revision: 1.3; previous revision: 1.2
done
floss$ cd /usr/local/newrepos/myproj/
floss$ ls
Attic/	      a-subdir/     foo.jpg,v
README.txt,v  b-subdir/     hello.c,v
floss$ ls Attic/
floss$ 

RCS 形式について知るべきことはもっとたくさんありますが、CVS のリポジト リの管理者としてはこれで十分だと思います。RCS ファイルを直接いじること は滅多にないことです。普通はせいぜいリポジトリ内のファイルのパーミッショ ンをいじったりする程度です、少なくともわたしが経験してきたところでは。 そうは言っても、CVS の動作が変になりはじめたら(稀ではありますが可能な範 疇を越えているわけではありませんから)、実際に RCS の中身を見てみて、何 が起こっているのか調べたくなるだろうと思います。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13 The CVSROOT/ Administrative Directory

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20CVSROOT/%20Administrative%20Directory"
"j-cvsbook/A.13TheCVSROOT/AdministrativeDirectory"へのコメント(無し)
検索全文Elisp

newrepos/CVSROOT/ の中のファイルはどのプロジェクトにも属していませんが、 そのリポジトリ内での CVS の動作を制御するために使用されます。それらのファ イルを編集するときには、普通のプロジェクトと同様、CVSROOT の作業コピー をチェックアウトするのがよいでしょう:

 
floss$ cvs co CVSROOT
cvs checkout: Updating CVSROOT
U CVSROOT/checkoutlist
U CVSROOT/commitinfo
U CVSROOT/config
U CVSROOT/cvswrappers
U CVSROOT/editinfo
U CVSROOT/loginfo
U CVSROOT/modules
U CVSROOT/notify
U CVSROOT/rcsinfo
U CVSROOT/taginfo
U CVSROOT/verifymsg
floss$ 

さて、重要な順(だいたい)にファイルを見ていくことにしましょう。各ファイ ルの最初には説明のコメントが入っていますので見てみてください(コメントの 書きかたはどのファイルも同じです。行頭に # があればコメントで、 CVS はファイルを解釈する時にそのような行を無視します)。チェックアウトし た作業コピー中の管理ファイルを変更しても、コミットするまでは CVS の動作 に何の影響も及ぼさない、ということを忘れないでください。

セキュリティを気にするのであれば、CVSROOT の Unix レベルのパーミッショ ンを適切に設定して、リポジトリの他のところのパーミッションと違うように しておきたいかもしれません。そうしておけば CVSROOT にコミットできるユー ザをきめ細かく制御できます。あとで出てきますが、CVSROOT のファイルを変 更可能にしておくということは、どんな CVS ユーザにも(リモートのユーザに も)リポジトリマシン上で任意のコマンドを実行する権利を与えてしまうことを 意味するのです。

A.13.1 The config File  
A.13.2 The modules File  
A.13.3 The commitinfo And loginfo And rcsinfo Files  
A.13.4 The verifymsg And rcsinfo Files  
A.13.5 The taginfo File  
A.13.6 The cvswrappers File  
A.13.7 The editinfo File  
A.13.8 The notify File  
A.13.9 The checkoutlist File  



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.1 The config File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20config%20File"
"j-cvsbook/A.13.1TheconfigFile"へのコメント(無し)
検索全文Elisp

config ファイルでは、グローバルな動作を決定するパラメータを設定し ます。形式は非常に厳しくて

 
PARAMETER=VALUE
(etc) 

余分なスペースは許されません。例えば、ありそうな config ファイルはこん な感じです:

 
SystemAuth=yes
TopLevelAdmin=no
PreservePermissions=no

(ここにないエントリは no と設定するのと等価です)

SystemAuth パラメータは、指定されたユーザ名が CVSROOT/passwd ファ イルに見つからなかった場合に、システムの passwd ファイルを見に行くかど うかを決定します。システムのセキュリティを守るため、ディストリビューショ ンではno に設定して出荷してあります。

TopLevelAdmin は作業コピーをチェックアウトするときに兄弟 CVS/ ディ レクトリを作るかどうかを決定します。兄弟 CVS/ ディレクトリは作業ディレ クトリ内ではなく、作業ディレクトリの隣に作成されます。同じリポジトリか ら多数のいろいろなプロジェクトをチェックアウトしたいと思う場合はこれを オンにすると便利です。そうでなければこれはオフのままにしておいたほうが いいでしょう、思いがけないところに余分な CVS/ ディレクトリができて混乱 しますからね。

PreservePermissions はファイルのパーミッションを保存し、同様のメ タデータをリビジョン履歴に記録します。これはある種の隠れ機能で、たぶん 詳しく説明する価値もありません。もし興味があるなら Cederqvist の

Special Files
ノードを見てください(ノードというのは、 Texinfo で、Info ドキュメントの中の特定の場所を示す言葉です。Info を読 んでいるときにあるノードに行きたければ、g をタイプしたあとにその ノードの名前を打てば、そのドキュメント中のどこからでも飛べます)

LockDir はほとんど使われない機能です。特殊な状況では、パーミッショ ンの問題で、CVS のロックファイルをプロジェクトのサブディレクトリ内に直 接作るのではなくもっと別のところに作るようにしたいかもしれません。ロッ クファイルというのは、同じリポジトリディレクトリ上で同時に複数の操作が 行われたとき、CVS がやりそこねるのを防いでいるものです。普通気にする必 要はありませんが、ときどきロックファイルを作れないことが原因でアップデー トやチェックアウトができなくて困るユーザがでてくるかもしれません(読むだ けの操作においても、CVS はロックファイルを作ります。他の CVS が書き込ん でいる最中に読んでしまうような状況を避けるためです)。通常このような問題 を解決するにはリポジトリのパーミッションを変更するのが普通ですが、それ ができないようなら LockDir パラメータが便利でしょう。

現在のところパラメータはこれだけですが、CVS の将来のバージョンでは新し いものが追加されるでしょう、Cederqvist やディストリビューション中の config ファイル自体をいつもチェックしておいてくださいね。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.2 The modules File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20modules%20File"
"j-cvsbook/A.13.2ThemodulesFile"へのコメント(無し)
検索全文Elisp

modules ファイルではリポジトリ内のプロジェクトの別名や alternate grouping を定義します。module の行は基本的に次の形式です:

 
MODULE_NAME   DIRECTORY_IN_REPOSITORY

例えば、

 
mp    myproj
asub  myproj/a-subdir

(右側で指定するパスはリポジトリのトップからの相対パスです。) 開発者がプ ロジェクトやプロジェクトの一部分をチェックアウトする時の別名を指定して います:

 
floss$ cvs co mp
cvs checkout: Updating mp
U mp/README.txt
U mp/foo.jpg
U mp/hello.c
cvs checkout: Updating mp/a-subdir
U mp/a-subdir/whatever.c
cvs checkout: Updating mp/a-subdir/subsubdir
U mp/a-subdir/subsubdir/fish.c
cvs checkout: Updating mp/b-subdir
U mp/b-subdir/random.c

あるいは

 
floss$ cvs -d /usr/local/newrepos/ co asub
cvs checkout: Updating asub
U asub/whatever.c
cvs checkout: Updating asub/subsubdir
U asub/subsubdir/fish.c

両方の場合で、モジュールの名前がどのように作業コピーのディレクトリ名になっ ているかを見てください。asub の場合、中間に myproj/ ディレクトリができな いですが、代りにトップレベルに asub ができました。リポジトリの myproj/a-subdir からできたにもかかわらずです。それらの作業コピー内では、 アップデート、コミット、その他の CVS コマンドがすべて正常に動きます。普 通と違うのは名前だけです。

ディレクトリ名のあとにファイル名をつけることによって、リポジトリディレ クトリ内の指定されたファイルで構成されたモジュールを定義することができ ます。例えば

 
readme  myproj  README.txt

 
no-readme  myproj  hello.c  foo.jpg

とすると、それぞれ、次のようなチェックアウトができるようになります:

 
floss$ cvs -q co readme
U readme/README.txt
floss$ cvs -q co no-readme
U no-readme/hello.c
U no-readme/foo.jpg
floss$

-a (alias という意味) を使えば複数のリポジトリディレクトリを含むモジュー ルを定義することができますが、チェックアウトするともとの名前のディレクト リができるので注意してください。たとえば、この行を書くと

 
twoproj  -a  myproj  yourproj

下のようになります(myproj/ と yourproj/ がリポジトリに存在するとします):

 
floss$ cvs co twoproj
U myproj/README.txt
U myproj/foo.jpg
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
U yourproj/README
U yourproj/foo.c
U yourproj/some-subdir/file1.c
U yourproj/some-subdir/file2.c
U yourproj/some-subdir/another-subdir/blah.c

twoproj はプロジェクトを両方持ってくるのに便利な名前ではあります が、作業コピーの名前には使われません。(There is no requirement that alias modules refer to multiple directories, by the way; we could have omitted twoproj, in which case myproj would still have been checked out under the name myproj.)

前にアンパサンドをつけることによって、別のモジュールを参照することもでき ます:

 
mp    myproj
asub  myproj/a-subdir
twoproj -a myproj yourproj
tp  &twoproj

tp をチェックアウトすると、twoproj のチェックアウトと完全 に同一の結果が得られます。

モジュールを処理する仕掛けはまだいくつかありますが、その大半は今述べたも のより使う機会が少ないです。それらについて知りたければ、Cederqvist の modules ノードを参照してください。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.3 The commitinfo And loginfo And rcsinfo Files

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20commitinfo%20And%20loginfo%20And%20rcsinfo%20Files"
"j-cvsbook/A.13.3ThecommitinfoAndloginfoAndrcsinfoFiles"へのコメント(無し)
検索全文Elisp

他の管理ファイルは、大半がコミット処理のさまざまな部分に programmatic な フックをしかけるためのものです(たとえばコミットを許可する前にログ メッセージやファイルの状態を検証するようにもできますし、リポジトリの特定 ディレクトリへのコミットが発生したら開発者グループに知らせるようにもでき ます)。

それらのファイルでは共通の文法を用います。各行はこのような形式です:

 
REGULAR_EXPRESSION    PROGRAM_TO_RUN

この正規表現は、コミットが起こるディレクトリに対してテストされます(リポ ジトリのトップディレクトリからの相対パス名)。マッチすれば指定したプログ ラムが実行されます。コミット処理中の各ファイル名がプログラムに渡されます; プログラムはそれらのファイル名を使って何でも好きなことができます、ファイ ルをオープンして内容を調べたりすることも含めてです。プログラムの終了コー ドがノンゼロの場合、コミットは実行されません。

(Regular expressions とは文字列のクラスを簡潔に記述するシステムで す。正規表現をよく知らないかたは、概略を手短に示しますので、これでとりあ えずなんとかなると思います: foo は文字列 foo を含むファイ ル名にマッチします。foo.*bar は、foo を含み、任意の数の文 字が続き、そのあとに文字列 bar が続くファイル名にマッチします。通 常の文字列はそれ自体にマッチしますが、.* は特殊だから です。. は任意の文字にマッチし、* は前の文字が任意の数(0含 む)だけ続いたものにマッチします。^$ はそれぞれ、文字列 の最初と最後にマッチします: ですから、^foo.*bar.*baz$fooで始まり、中ほどのどこかに bar を含んでおり、そして baz で終わる文字列とマッチします。ここではこのくらいにしておきま しょう、この概略説明は正規表現の文法全てのうち、かなり省略されたサブセッ トです)

commitinfo ファイルでは全てのコミット時に実行したい汎用的フックを 書きます。commitinfo の行の例をいくつか示します:

 
^a-subdir*     /usr/local/bin/check-asubdir.sh
ou             /usr/local/bin/validate-project.pl

myproj/a-subdir へコミットすると最初の行にマッチするので、 check-asubdir.sh スクリプトが実行されます。文字列 ou を含む名前の プロジェクト(実際のリポジトリディレクトリ名であってモジュール名である必 要はありませ)へコミットすると、 validate-project.pl スクリプトが実行され ます。ただし、既に a-subdir の行にマッチしたコミットは除きます。

正規表現の個所に DEFAULT あるいは ALL という語を使うことが できます。DEFAULT 行(もし2つ以上ある場合は最初の DEFAULT 行)はどの正規表 現にもマッチしなかった場合に実行され、各 ALL 行はマッチする他の行に加え て実行されます。

プログラムに渡されるファイル名は RCS ファイルを指すものではありません、 コミットされつつある作業コピーと同じ内容の通常のファイルを指します。CVS はそのファイルをリポジトリ内に一時的に置き、プログラムはリポジトリの中で そのファイルを使うことができます、あまり普通ではありませんね。

loginfo ファイルは commitinfo と同じですが、ファイルの内容ではなく ログメッセージに作用します。loginfo ファイルの左側は正規表現で、DEFAULT や ALL 行も書けます。右側のプログラムは標準入力からログメッセージを受け 取ります。その入力を使って好きなことができます。

右側にあるプログラムは任意の数のコマンドライン引数を取ることもできま す。引数のうちのひとつは特殊な % コードを書いてもよく、それは CVS によって実行時に次のように展開されます:

 
%s    ------>      コミットされつつあるファイルの名前
%V    ------>      コミット前のリビジョン番号
%v    ------>      コミット後のリビジョン番号

展開された文字列の最初はリポジトリサブディレクトリ(リポジトリのトッ プディレクトリからの相対パス)で、そのあとに各ファイルの情報が続きま す。たとえば、コミットされたファイルが foo, bar, baz で、それらがす べて `myproj/a-subdir' の中にあった場合、%s は次のように 展開されます。

 
myproj/a-subdir  foo  bar  baz

そして %V は古いリビジョン番号に展開されます

 
myproj/a-subdir  1.7  1.134  1.12

and %v their new revision numbers:

 
myproj/a-subdir  1.8  1.135  1.13

% 記号に続けて中括弧でくくることによって、% 表現を結合 することができます。コミット時に、各ファイルごとの対応する情報をカン マで区切ったサブリストに展開されます。例えば、 %{sv} は次の ように展開されます:

 
myproj/a-subdir  foo,1.8  bar,1.135  baz,1.13

%{sVv} だとこのように展開されます:

 
myproj/a-subdir  foo,1.7,1.8  bar,1.134,1.135  baz,1.12,1.13

(カンマとピリオドを見間違えないよう、注意して見て下さい)

loginfo ファイルのサンプルを示します:

 
^myproj$   /usr/local/newrepos/CVSROOT/log.pl -m myproj-devel@foobar.com %s
ou         /usr/local/bin/ou-notify.pl  %{sv}
DEFAULT    /usr/local/bin/default-notify.pl  %{sVv}

最初の行では、リポジトリの myproj サブディレクトリへのコミットが発生 すると `log.pl' を起動するよう設定しています。`log.pl' の 引数として、電子メールアドレス(`log.pl' はそのアドレスへログメッ セージを送信すします)、リポジトリ、コミットされたファイルを渡します。

2行目では、リポジトリの文字列 ou を含むサブディレクトリへのコ ミットが発生すると `ou-notify.pl' (架空のものです)を起動するよ う設定しています。リポジトリのあとに、ファイル名と新しいリビジョン番 号をリストで渡します。

3行目では、上記2行にマッチしないコミットが発生した時に `default-notify.pl' を起動するよう設定しています。渡せる情報は 渡しています(リポジトリパス、ファイル名、古いリビジョン番号、新しい リビジョン番号)。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.4 The verifymsg And rcsinfo Files

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20verifymsg%20And%20rcsinfo%20Files"
"j-cvsbook/A.13.4TheverifymsgAndrcsinfoFiles"へのコメント(無し)
検索全文Elisp

ログメッセージがある一定の標準に従っているかどうか自動的に検証して、 従っていなければコミットを中止するようなプログラムが欲しいこともある と思います。これは、verifymsg を使えば実現できます。 補助に rcsinfo も使うかもしれません。

verifymsg ファイルは例によって正規表現とプログラムを結び付ける ものです。プログラムは標準入力からログメッセージを受け取って、そのロ グメッセージがある基準に沿っているかどうかチェックして、ゼロまたはノン ゼロの終了コードで終了します。ノンゼロで終了した場合はそのコミットは 失敗します。

一方、rcsinfo の左側はいつもの正規表現ですが、右側はプログラムではな くてテンプレートファイルを指定します。テンプレートファイルというのは このようなものです

 
Condition: 
Fix: 
Comments: 

こんな感じの、有効なログメッセージの形式を満たすために記入する必要の あるフィールドの集合です。開発者みんなが -m オプションを使ってコミッ トする場合にはあまり有用ではありませんが、多くはそうではないでしょう。 -m で指定するかわりに

 
floss$ cvs commit

を実行して、CVS が自動的にテキストエディタ(EDITOR 環境変数で指定して あるやつです)を起動するのを待って、そこにログメッセージを記入し、セー ブして終了します。そのあと、CVS はコミット処理を続けます。

このシナリオに沿う場合、rcsinfo テンプレートはユーザがタイプする前に エディタ中に挿入されますので、記入すべきフィールドが表示されます。 ユーザがコミットした時点で `verifymsg' 中で指定された適切なプロ グラムが起動されます。ログメッセージがフォーマットに沿っているかチェッ クし、結果が終了コードに反映されます(ゼロの場合成功)。

検証プログラムに便利なように、verifymsg のプログラムの最後の 引数として、テンプレートへのパスが rcsinfo ファイルから追加されます。 なので、お望みならテンプレートをもとに検証処理ができます。

リモートマシンへ作業コピーをチェックアウトした場合には、対応する rcsinfo テンプレートファイルもクライアントに送信されます(作業コピー の CVS/ サブディレクトリに保存されます)。しかしこれは、チェックアウ トより後にサーバ上の rcsinfo ファイルが変更された場合、クライアント 側からはその変更が再度チェックアウトしない限りわからないということに なるので注意して下さい(update しただけではダメなんです)。

また、verifymsg ファイルでは ALL キーワードがサポートされていないこ とに注意して下さい(DEFAULT はサポートされているのですが)。デフォルト の検証スクリプトを、サブディレクトリ向けのスクリプトでオーバライドし やすくなっているのです。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.5 The taginfo File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20taginfo%20File"
"j-cvsbook/A.13.5ThetaginfoFile"へのコメント(無し)
検索全文Elisp

loginfo がログメッセージに対して行うようなことを、taginfo はタグに対 して行います。taginfo の左側は例によって正規表現で、右側はプログラム です。cvs tag の起動時、各プログラムには自動的に引数が渡されます。順 序は次の通り:

 
arg 1:          タグ名
arg 2:          オペレーション種別 ("add" => tag, "mov" => tag -F, "del" => tag -d) 
arg 3:          リポジトリ
arg 4, 5, etc:  ファイルリビジョン [ファイルリビジョン ...] 

プログラムがノンゼロを返した場合、tag コマンドは中断されます。

tag コマンドの -F オプションについてまだ説明していませんでしたね、で も上に書いてあることでわかると思います: タグをあるリビジョンから別の リビジョンへ移動します。例えば、Known_Working というタグがあ るファイルのリビジョン1.7につけられていて、それをリビジョン1.11につ けなおしたい場合には、こうします

 
cvs tag -r 1.11 -F Known_Working foo.c

こうすると1.7(またはそのファイルでそのタグがつけられていたところ)か らはタグが削除され、1.11につけられます。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.6 The cvswrappers File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20cvswrappers%20File"
"j-cvsbook/A.13.6ThecvswrappersFile"へのコメント(無し)
検索全文Elisp

cvswrappers ファイル(くどい名前ですよね)は、どのファイルをバイナリと して扱うかをファイル名によって指定するものです。CVS は、たとえば .jpg ファイルをすべて JPG 画像データと見なしたりはしないので、JPG ファ イルを追加するときに自動的に -kb オプションをつけたりはしてくれません。 ですが、プロジェクトによっては JPG ファイルはすべてバイナリだと指定 できればとても便利です。次のような行を cvswrappers ファイルに書けば そのようなことができます:

 
*.jpg -k 'b'

b が離れており、クオートされています。RCS の展開モードキーワー ドは b だけではないからです。o を指定すると $ は展開するが改行の変換は行わないという意味になります。しかし、 b は最も普通のパラメータではあります。

wrappers ファイルから指定できるモードはあといくつかありますが、滅多 にない状況のためのものなので、ここに書くほどの価値はありません(意訳: 著者はそれらを使ったことがありません)。好奇心旺盛なアナタは Cederqvist の

Wrappers
ノードを参照してくださいね。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.7 The editinfo File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20editinfo%20File"
"j-cvsbook/A.13.7TheeditinfoFile"へのコメント(無し)
検索全文Elisp

このファイルはもう obsolete です、ディストリビューションにただ含まれ ているだけです。無視して下さい。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.8 The notify File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20notify%20File"
"j-cvsbook/A.13.8ThenotifyFile"へのコメント(無し)
検索全文Elisp

このファイルは CVS の watch 機能とともに用いられるものです。 watch 機能については Advanced CVS を参照のこと。watch (便利ですが必須の機能ではありません)というのが何かわからなければ何を 書いても意味ありませんので、このファイルと watch について詳しくは Advanced CVS をお読み下さい。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.13.9 The checkoutlist File

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=The%20checkoutlist%20File"
"j-cvsbook/A.13.9ThecheckoutlistFile"へのコメント(無し)
検索全文Elisp

CVSROOT/ の中を見ると、ファイルの作業コピーが RCS リビジョンファイル と並んでいるのが見えると思います:

 
floss$ ls /usr/local/newrepos/CVSROOT
checkoutlist     config,v       history     notify     taginfo
checkoutlist,v   cvswrappers    loginfo     notify,v   taginfo,v
commitinfo       cvswrappers,v  loginfo,v   passwd     verifymsg
commitinfo,v     editinfo       modules     rcsinfo    verifymsg,v
config           editinfo,v     modules,v   rcsinfo,v

floss$ 

CVS がその動作を決める際にはその作業バージョンだけを見て、RCS ファイ ルは見ません。従って、CVSROOT/ の作業コピーをコミットすると(別のマシン にチェックアウトされていようとも)、CVS は自動的にリポジトリ内のファ イルを更新します。コミットの最後に次のようなメッセージが表示されるの で、何が起きたかわかると思います:

 
floss$ cvs ci -m "added mp and asub modules" modules
Checking in modules; 
/usr/local/newrepos/CVSROOT/modules,v  <--  modules
new revision: 1.2; previous revision: 1.1
done
cvs commit: Rebuilding administrative file database

CVS は標準の管理ファイルに何があったか知っていて必要に応じて CVSROOT/ を再構築します。CVSROOT/ 中にカスタムファイルを置きたければ (プログラムや rcsinfo テンプレートファイル等)、他のファイルと同様に 扱うよう、CVS に明示的に伝えなければなりません。

これを伝えるために、checkoutlist ファイルがあります。今まで見てきた ファイルとは違うフォーマットになります。

 
FILENAME     ERROR_MESSAGE_IF_FILE_CANNOT_BE_CHECKED_OUT

例えば、

 
log.pl           unable to check out / update log.pl in CVSROOT

bugfix.tmpl      unable to check out / update bugfix.tmpl in CVSROOT

CVSROOT 中のいくつかのファイルは、伝統的にリビジョン管理下には置かな いことになっています。1つは history で、これはリポジトリ中の全 ての操作の a running record を保持しており、cvs history コマンドが使用します(このコマンドは指定されたファイルまたはプロジェ クトディレクトリについて、チェックアウト、アップデート、タグ付けの状 況の一覧を表示します)。 偶然 `history' ファイルを削除してしまっ たら、CVS はログを取るのをやめます。

注意: history ファイルがパーミッション問題の原因になることがあります が、解決するにはファイルをワールドライタブルにするか、ただ削除するか してください。

リビジョン管理されていないファイルには他に passwd ファイルが あります。それがネットワーク越しにチェックアウトされたとしたら、パス ワードの信頼性を損うからです(たとえ暗号化されていようとも)。passwd を checkoutlist に追加するかどうかは、守るべきキュリティの状況を鑑み て決定してください。デフォルトでは checkoutlist に入っていません。

CVSROOT/ ディレクトリについて最後に2つほど: すごいミスをして、壊れた 管理ファイルをコミットしたあげくどんなコミットも全く実行できなくなっ たとしましょう。ありうる話です。もしそうなったら、管理ファイルを直し てコミットしなおそうとしても、当然できないわけです。これを解決するに は、管理ファイルのリポジトリ内の作業コピーを手で編集して直します。直 せるまで、リポジトリ全体がアクセス不可の状態のままになります。

また、セキュリティを確保するため、CVSROOT/ ディレクトリは信頼できる ユーザのみが書き込めることを確認してください(信頼できるという のは、その人にパスワードの信頼性を損わないだけの能力があってその努力 ができることを信頼できる、という意味です)。`*info' ファイルは任 意のプログラムを実行できる権限を与えてしまうので、CVSROOT/ ディレク トリ中のファイルをコミットまたは編集できる人はすなわち、基本的にはシ ステムのどんなコマンドでも実行できるということです。このことは心に留 めておくべきです。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.14 Commit Emails

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Commit%20Emails"
"j-cvsbook/A.14CommitEmails"へのコメント(無し)
検索全文Elisp

loginfo ファイルはコミットメール、すなわちコミットが発生した時にプロ ジェクトで作業している全員に送信される自動電子メールを設定できます。 (commitinfo ではなく loginfo で設定するというのは直観に反するように 見えるかもしれませんが、ポイントはメールにログメッセージを含めたいと いうところです) 配送プログラム(CVS のソースディストリビューション に入っている `contrib/log.pl')はシステム上のどこにインストール してもかまいません。わたしはリポジトリの CVSROOT/ サブディレクトリ内 に置くのを週間にしていますが、それはただ好みの問題です。

システム上でうまく動くようにするため、ほんの少しだけ `log.pl' を編集する必要があるかもしれません、おそらく Perl インタプリタを指す 最初の行と、あとは多分この行

 
$mailcmd = "| Mail -s 'CVS update: $modulepath'";

をお好みのメーラ(Mailという名前かもしれないし違うかもしれない) を起動するように直すくらいでしょう。好きなように設定し終わったら、 loginfo ファイルに下記と同じ行を書き加えてください:

 
listerizer CVSROOT/log.pl %s -f CVSROOT/commitlog -m listerizer@red-bean.com
RoadMail   CVSROOT/log.pl %s -f CVSROOT/commitlog -m roadmail@red-bean.com
bk/*score  CVSROOT/log.pl %s -f CVSROOT/commitlog -m \
                                        bkscore-devel@red-bean.com

%s はコミットされたファイルの名前に展開されます。 `log.pl' の -f オプションはファイル名を取り、そのファイルにログ メッセージが追加されます(ですから CVSROOT/commitlog は永久に成長する ログメッセージのファイルになります)。-m フラグはメールアドレスを取り、 `log.pl' はそのアドレスへコミットのメッセージを送信します。そこ に書くアドレスは通常メーリングリストですが、ひとつの log.pl コマンド ラインに -m オプションを必要なだけ並べることもできます。



[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [表紙] [目次] [索引] [検索] [上端 / 下端] [?]

A.15 Finding Out More

URL="http://www.bookshelf.jp/cgi-bin/goto.cgi?file=j-cvsbook&node=Finding%20Out%20More"
"j-cvsbook/A.15FindingOutMore"へのコメント(無し)
検索全文Elisp

この章で CVS のインストールと管理を完全に紹介しようと思ったのですが、 あまりにも使うことがなくて言及する価値がない事柄や、既に Cederqvist マニュアルで十分説明されているようなことを積み残してしまいました。後 者に属することとしては、他のリモートアクセス方法、RSH/SSH, kserver (ケルベロス4), GSSAPI(ケルベロス5等を含む) の設定が挙げられます。問 題のユーザがリポジトリマシンへ RSH か SSH でログインできることを確認 する以外に何も特別なことをする必要がない、ということだけは言っておく べきでしょう。それができて、クライアントにもサーバにも CVS がインス トールしてあって、サーバマシンで直接リポジトリを使える正しい権限があ れば、:ext: メソッドを経由してリモートからリポジトリにアクセスできま す。

CVS の機能のうち特殊ないくつかは、のちほどの章で説明してありますので、 その機能が明らかに便利だとわかる文脈のなかで紹介します。一般的な CVS のトラブルシューティングのコツについては Tips And Troubleshooting に書いてあります。 Cederqvist マニュアル全部を読む 必要はありませんが、親しんでおくべきです。貴重なリファレンスツールで すから。もし何か理由があってあなたのマシンで Info が動かなくて、マニュ アルをプリントアウトするのもダメなら、オンラインで http://durak.org/cvswebsites/doc/ または http://www.loria.fr/~molli/cvs/doc/cvs_toc.html で閲覧できま す。


[ << ] [ >> ]           [表紙] [目次] [索引] [検索] [上端 / 下端] [?]