Gentoo Logo

Gentoo Linux CVSチュートリアル

目次:

1.  はじめに

チュートリアルの構成

このチュートリアルはふたつのパートに分かれています。前半では、たとえば CVSからソースを取ってきていつも新しい状態に保つといった、 非開発者としてのCVSの使い方を説明します。 後半では、CVSで管理しているファイルを変更したり追加したり削除したり、 その他開発者らしい作業を実行するための方法を紹介します。 あまりCVSに親しんでいないようなら、まずは前半を読んで、 それから後半に進んだ方が良いでしょう。 CVSの経験はあるけれど一人前の開発者としてCVSを使うのは初めてという人は、 後半を読めばあなたが必要としていることは全て見つかるでしょうが、 確認の意味でも、一旦前半も通して読んだ方が良いでしょう。

CVSって何? 何ができるの?

CVSは、開発者が自分たちのプロジェクトをリポジトリと呼ばれる特定の場所に集中して蓄積できる、 クライアント・サーバシステムです。 CVSのクライアント用ツールを利用すれば開発者はリポジトリの内容を変更することができます。 そしてCVSリポジトリは全てのファイルに対する全ての変更を記録し、 その開発プロジェクトの完全な進化の履歴を作り上げます。 開発者は、特定のソースファイルの古いバージョンを取ってきたり、 変更内容のログを見たり、 その他必要になるであろう有用な作業を実行することができます。

CVSの役割

たくさんのオープソースソフトウェア・プロジェクトが自分たちのCVSリポジトリを持っており、 そのリポジトリは開発者たちに彼らの全作業の中央リポジトリとして利用されています。 開発者はしばしば、日課としてCVSリポジトリ上のファイルに改良を加えます。 そしてその開発者たちが世界中に散らばっていることもよくあることなので、 CVSはそのプロジェクトをひとつにまとめて統合するために必要なメカニズムを提供しています。 CVSは、開発者たちが、お互いに膝を付き合わせたりとか、 大事なデータを無くしてしまったりとか、 または特定のソースファイルに対するそれぞれのクリティカルな更新を失なってしまったりとか、 そういったことがないように「組織化された糊」を作ってくれます。

CVS −− 最新版の開発版ソース

もろもろ出来上がったところで、開発者はCVSにある最新の作業の成果物をひとつのtar.gzファイルにまとめ上げ、 そのソフトウェアパッケージの最新オフィシャルバージョンとしてリリースします。 しかし、様々な理由により、その最新のオフィシャルリリースでは充分に新しくなくなってしまった、ということがあります。 このチュートリアルの前半では、こんなとき−−自分の個人的な用途として、 最新かつ偉大な、開発者バージョンのソースコードを入手したいとき −−にどうやってCVSを使ったら良いかを説明します。

CVS −− そもそも持ってますか?

実際にCVSを使い始める前に、自分のシステムにCVSをインストールしなくてはいけません。 それを調べるのに一番簡単なのは、以下のようにタイプしてみることです:

コード表示 1.1: CVSを始める

# cvs

cvsコマンドが見つかれば、すでにインストールされているということになります。おめでとう!  が、見つからないようなら、自分が使っているディストリビューション用に用意されたバイナリパッケージを取ってくるか、 もしくはソースからインストールすることになります。 実際のところ、CVSをソースからインストールする作業はとても簡単です。 次のパネルでその方法をお見せします。

(訳注:これを読んでいる人が混乱するといけないので書いておきますが、 このページの最後にもあるように、 このドキュメントはGentooのドキュメント用に書かれたものではありません。 「次のパネル」という言葉が出てきたり、 ソースからのインストール方法が説明されたりしているのは、このためです )

CVSをソースからインストールする

CVSをソースからインストールするのは簡単です。まず、ftp://ftp.cvshome.org/pub/cvs-1.11/cvs-1.11.tar.gzからcvs-1.11.tar.gzというtarボールを取ってきます( もしここにもっと新しいバージョンが挙げられているようなら、 その新しいバージョンを代わりに取ってきた方が良いでしょう )。 次に以下のような作業をします(スペースの関係で各コマンドの出力は省略します):

コード表示 1.2: tarボールを使ったCVSのインストール

# tar xzvf cvs-1.11.tar.gz
# cd cvs-1.11
# ./configure
# make
# make install

さあ、これで準備が出来ました。

CVSROOT

先に進む前に、いくつか知っておかなくてはいけない、CVSの基本的な事柄があります。 まず、CVSリポジトリに接続しなくてはいけないので、 「CVSROOT」と呼ばれるパスについて知らないといけません。 CVSROOTはURLのような文字列で、cvsコマンドに、 どこにリモートのリポジトリがあってどうやってそこに接続したいのかということを伝えます。 おもしろいことに、 CVSリポジトリがローカルにあるのかリモートにあるのか、 そのリポジトリにどうやって接続したいのかによって、 CVSにはたくさんの種類のCVSROOTのフォーマットがあります。 説明を加えつつ、いくつかCVSROOTの例を紹介していきましょう・・・

ローカルの場合のCVSROOT

コード表示 1.3: CVSROOTを設定

CVSROOT=/home/cvsroot

ローカルにあるCVSROOTパスの例です。/home/cvsrootにあるローカルリポジトリ、 もしくはNFSで/home/cvsrootにマウントされているリポジトリに接続したい場合は、 上にあるようなCVSROOTを使います。

リモートのパスワードサーバ(password server)の場合のCVSROOT

コード表示 1.4: 認証付きのCVSROOTを設定

CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot

これはリポジトリがリモートのfoo.bar.comに存在し、 そのマシンに/home/cvsrootがある場合の例です。 先頭にある「:pserver:」という部分は、クライアントがこのリモートマシンに接続する場合、 CVSに組み込みで備わっているCVSパスワードサーバ(CVS password server)プロトコルを使用するように伝えるためのものです。 典型的な例としては、 パブリックなCVSリポジトリはアノニマス・ユーザーを受け付けるためにこのプロトコルを使っています。

リモートのRSH/SSH方式の場合のCVSROOT

コード表示 1.5: RSH/SSH方式の場合のCVSROOTを設定

CVSROOT=drobbins@foo.bar.com:/data/cvs

RSHやSSHプロトコルの場合のCVSROOTはこの例のようになります。 この例では、CVSサーバはfoo.bar.comにあるリポジトリにdrobbinsというアカウントを使ってアクセスを試みます。 CVS_RSHという環境変数が「ssh」となっていた場合、cvsクライアントは接続の際にSSHを使用し、 そうでない場合はRSHを使用します。セキュリティを心配する人たちの間ではSSHで接続を行う方法が人気があります。 ただ、いずれの方法でも、アノニマス・ユーザーがソースを取得することはできません。 この方式を利用する場合、 foo.bar.comにログインアカウントを持っている必要があります。

それとあともう少し・・・

CVSROOTに加えて、あなたがチェックアウトしたいモジュール(ソースの集合体)の名前や、 CVSパスワードサーバにログインするためのアノニマス・ユーザー用のパスワードも知っている必要があります。 アノニマスFTPとは違って、アノニマス・ユーザー用のパスワードの形式に「スタンダード」なものはありません。 ですから、開発者のWebサイトや開発者自身から、そのためのパスワードを入手する必要があります。 これらの情報が揃ったら、始める準備が整ったことになります。

CVSを使ってみる、その1

ソースコードの取得は2段階のプロセスです。まず、 パスワードサーバにログインします。 それからcheckoutコマンドを使ってソースを取得します。 以下は最新のSAMBA(有名なUNIX/Windows統合プロジェクト)のソースをチェックアウトする際に使用するコマンドの例です:

コード表示 1.6: CVSROOTを設定する

# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot

最初のコマンドではCVSROOT環境変数をセットします。この環境変数をセットしない場合は、 続くふたつのコマンドでcvsコマンドに続けて-d :pserver:cvs@pserver.samba.org:/cvsrootと追加する必要があります。 CVSROOTをexportしておけば多少タイプ量を減らすことができます。

CVSを使ってみる、その2

以下のようにすることで、開発者用ソースの最新版のコピーを入手することができます。 一旦次のパネルに飛んでこれらのコマンドに関する説明を読んでから、 再度ここに戻ってくると良いでしょう:

コード表示 1.7: ソースをチェックアウトする

# cvs login
(cvs@pserver.samba.orgにログイン)
CVS password: (ここでパスワードを入力)

# cvs -z5 co samba
U samba/COPYING
U samba/Manifest
U samba/README
U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
(これはcvs coでの出力の断片です)

CVSを使ってみる−−説明

まず上記の最初のコマンドでpserverにログインし、次のコマンドで、 遅い回線越しの転送をスピードアップするためgzipの圧縮レベルを5に設定(-z5)しつつ、 SAMBAのモジュールをチェックアウト(co)するようにCVSクライアントに伝えます。 ローカルで新しいファイルが作られるごとに、 CVSはそのファイルがディスク上で更新されたことを示す「U [path]」を出力します。

チェックアウト完了

チェックアウトコマンドが完了すると、 カレントディレクトリに最新のソースを含んだ「samba」というディレクトリが出来ていることがわかると思います。 また、各ディレクトリの中に「CVS」というディレクトリ(CVSはこのディレクトリ以下にアカウント情報を保存します。このディレクトリは作業等に影響は与えません)が存在することにも気が付くと思います。 このことから、CVSROOT環境変数をセットし忘れる心配や、コマンドラインでCVSROOTを指定する必要は、 全然ないということがわかると思います。 それらについてはもう、各ディレクトリに追加された「CVS」ディレクトリにキャッシュされているわけですから。 覚えておいてください−−CVSROOTを設定する必要があるのは、 最初のログイン時とチェックアウトのときだけです。

ソースを更新する

お待たせしました−−新鮮なソースです!  これでソースが手に入ったわけですから、 コンパイルしてインストールするも良し、 中をじっくり見るのも良し、 何でも好きなことをしてください。

これからは気が向いたときに、手元にあるチェックアウトしたソースディレクトリを、 CVSにある最新バージョンと同期された状態にしておきたいことでしょう。 そのために再度pserverにログインする必要はありません。 あなたのアカウントの情報はCVSによってそれぞれの「CVS」ディレクトリにキャッシュされています。 まずメインのチェックアウトしたディレクトリ(この場合は「samba」)に入り、 以下のように入力してください:

コード表示 1.8: 手元のソースを更新する

# cvs update -dP

「cvs update」の詳細、その1

新しいファイルがあれば、CVSはそれぞれを更新するたびに「U [path]」という行を表示します。 また、もしあなたがソースをコンパイルしたようなら、 恐らく大量の「? [path]」という行を目にするでしょう。 これらはオブジェクトファイルで、CVSは、 これらがリモートのリポジトリから来たものではないことを教えてくれているわけです。

「cvs update」の詳細、その2

「cvs update」に指定したふたつのコマンドラインオプションにも注目してください。 「-d」はリポジトリに追加されたディレクトリを新しく作成するためで(デフォルトではこの作業はやってくれません)、 「-P」オプションは、 ソースがコピーされたローカルのチェックアウト・ディレクトリにある、 空のディレクトリを削除するためのものです。 CVSは毎回大量の空の(つまり、一度使用されたがもう使われていない)ディレクトリを集めがちですから、 「-P」オプションを付けておくのは良い方法だと思います。

単に最新版のソースを手に入れたいだけなら、 あなたが知っておく必要があるのはだいたいこれで全部です。 続いて、CVSを開発者として使用する方法について見ていくことにしましょう。

2.  開発者のためのCVS

ファイルを編集する

開発者として、あなたはCVS上のファイルを編集する必要があります。そのためには単純に、 手元にあるリポジトリのローカルコピーを適宜変更してください。 あなたが加えた変更は、cvsコマンドでその変更を「コミット」するまではリモートのリポジトリには反映されません。 自分で加えた全ての変更をテストし、全てがきちんと動作することを確認したら、 その変更をリポジトリに反映する準備が整ったことになります。 次のふたつのステップを実行してください。 まず、メインのソースディレクトリで以下のように入力して、 あなたのソースを最新のものにします:

コード表示 2.1: ソースとディレクトリを更新する

# cvs update -dP

CVSで他人が加えた変更をマージする

前述したように、「cvs update」を行うことであなたのソースはリポジトリに基づいて最新バージョンのものになります−− では、あなたが加えた変更はどうなってしまったのでしょうか?  心配する必要はありません。別にどこかに行ったわけではありません。 あなたが触っていないファイルを他の開発者が変更した場合、 手元のファイルは更新され、リポジトリ上のバージョンと同期が取れた状態になります。

ここであるローカルファイルについて以下のようなことが起こっていたとしましょう。 あなたは1行目から10行目を編集しました。別の開発者は40行目から50行目を削除し、 末尾に12行を追加し、30行目から40行目までを編集し、 あなたより先にリポジトリにコミットしました。 賢いことにCVSはこれらの変更をあなたの手元の編集済のコピーに適用するので、 あなたが加えた変更は全く失われません。 このおかげで、ふたり以上の開発者が、 同じファイルのそれぞれの場所について同時に作業できるわけです。

マージは完全ではない

しかしながら、複数の開発者が同じファイルの同じ場所に変更を加えてしまった場合、 話はちょっとややこしくなります。このような場合、 CVSはあなたにコンフリクト(衝突)が起こったことを知らせます。 失われる作業はありませんが、 CVSはコンフリクトを起こしたあなたの分の変更をどうやってマージすれば良いかわからないので、 多少、手でなんとかしてやる必要があります。

コミット

コンフリクトを解消する方法について見ていくのは少し置いておいて、 とりあえずは、「cvs update -dP」を実行したあと特にコンフリクトが起こらなかったと仮定しましょう −−実際、コンフリクトが起こることはあまりありません。 コンフリクトが起こってなければ、あなたの手元のソースは最新版になっており、 メインのソースディレクトリの中で以下のように入力することで、 自分の変更分をコミットする準備が整ったことになります:

コード表示 2.2: 変更をコミットする

# cvs commit

コミットするとどうなるのか

「cvs commit」は単にあなたの変更をリポジトリに反映するだけではありません。 実際にリモートのリポジトリに変更を反映する前に、 CVSはあなたのデフォルトエディタを起動します。 ですから、あなたは自分が加えた変更について説明を入力することができるわけです。 コメントを入力したら、ファイルを保存してエディタから抜けてください。 あなたの変更(とコメント)はリモートのリポジトリに反映され、 同じチームの他の開発者がそれを使うことができるようになります。

ログを見る

各開発者(あなたも含めて)がコミット時に加えたコメントがあるので、 ある特定のファイルについて完全な履歴を見るのは本当に簡単なことです。 この情報を見たい場合は、以下のように入力します:

コード表示 2.3: ログの情報を見る

# cvs log myfile.c

「cvs log」コマンドは再帰的に処理を行うので、全ディレクトリツリーについての完全なログが見たい場合は、 単にディレクトリの中で以下のように入力すれば大丈夫です:

コード表示 2.4: ログの情報をページャで見る

# cvs log | less

コミットのオプション

「cvs commit」を実行したとき、CVSがデフォルトで起動するエディタ以外のエディタを使いたい場合もあるでしょう。 その場合は、EDITOR環境変数にあなたが使いたいエディタの名前をセットしておけば大丈夫です。 以下のような設定を自分の~/.bashrcに入れておけば良いと思います:

コード表示 2.5: EDITORを設定する

export EDITOR=jpico

他の方法としてはコマンドラインオプションとしてログ用のメッセージを指定してしまう方法もあります。 そうすれば最初のやり方と違って、CVSがエディタを起動する必要はありません:

コード表示 2.6: ちょっとしたログの情報と共に変更をコミットする

# cvs commit -m 'I fixed a few silly bugs in portage.py'

.cvsrcファイル

CVSのコマンドをもっと詳しく見ていく前に、 ~/.cvsrcファイルを設定しておくことをお勧めします。 .cvsrcファイルを自分のホームディレクトリに作っておけば、 デフォルトで使いたいコマンドラインオプションをCVSに与えることができるので、 毎回毎回オプションを忘れないで入力する必要がありません。 以下は.cvsrcファイルのオススメのデフォルトです:

コード表示 2.7: オススメのデフォルト

cvs -q  
diff -u -b -B
checkout -P
update -d -P

.cvsrcファイル、のつづき

一連のCVSのコマンドに役に立つオプションを設定するのに加えて、 .cvsrcの1行目では、CVSがquietモードで実行されるようにしています。 こうする一番のメリットは、cvs updateの出力をよりわかりやすく、より読みやすくすることです。 もちろん、この.cvsrcを置いておけば、cvs update -dPと入力する代わりにcvs updateと入力するだけで良くなります。

リポジトリにファイルを追加する

CVSにソースファイルを追加するのはとても簡単です。まず好きなテキストエディタでファイルを作成します。 次に以下のように入力します:

コード表示 2.8: ファイルを追加する

# cvs add myfile.c
cvs server: use 'cvs commit' to add this file permanently

こうすることで、次にcvs commitを実行したときにこのファイルをリポジトリに追加することを予約したことになります。 コミットするまでは他の開発者はこのファイルを見ることはできません。

リポジトリにディレクトリを追加する

リポジトリにディレクトリを追加する場合も同様です:

コード表示 2.9: ディレクトリを追加する

# mkdir foo
# cvs add foo
Directory /home/cvsroot/mycode/foo added to the repository   

ファイルを追加する場合と違って、ディレクトリをaddした場合ディレクトリがすぐにリポジトリに追加されたように、つまりコミットが必要でないように見えます。 ローカルのディレクトリをCVSに追加すると、 CVS用のアカウント情報の入れ物を提供するため、 「CVS」というディレクトリがその中に追加されることがわかるでしょう。 このためあるディレクトリがCVSに追加されたかどうかは、 「CVS」というディレクトリが中にあるかどうか探せばすぐに分かります。

「cvs add」に関する注意

そうそう、ご想像の通り、ファイルやディレクトリをリポジトリに追加する前には、 その親ディレクトリがすでにCVSに追加されている必要があります。 そうじゃないと、以下のようなエラーが表示されるでしょう:

コード表示 2.10: ファイルを追加、でもエラー発生

# cvs add myfile.c
cvs add: cannot open CVS/Entries for reading: No such file or directory
cvs [add aborted]: no repository  

「cvs update」について詳しくなる、パート1

コンフリクトを解消する方法に移る前に、 「cvs update」コマンドの出力について詳しくなっておきましょう。 「cvs -q」を含んだ~/.cvsrcファイルを作成しているなら、 「cvs update」の出力が断然見やすくなったことがわかるでしょう。 「cvs update」は処理結果を、 状態を表す文字、スペース、それからファイル名で表示します。 以下の例のように:

コード表示 2.11: CVSを更新する

# cvs update -dP
? distfiles
? packages
? profiles 

「cvs update」について詳しくなる、パート2

「?」が表示された場合、そのファイルはリポジトリのローカルコピーの中では見つかったけれど、 CVSはそのファイルについて何も知らないということを意味します。 そのファイルは正式にはリポジトリの一部ではないし、 今後追加される予定もないということです。 以下、CVSが情報として表示する文字のリストです:

コード表示 2.12: 表示される文字: U

U [path]

ローカルのリポジトリに新しいファイルが追加されたか、 (あなたが)未編集のファイルが更新されました。

コード表示 2.13: 表示される文字: A

A [path]

このファイルは追加予定で、 次にcvs commitを実行したとき正式にリポジトリに追加されます。

「cvs update」について詳しくなる、パート3

コード表示 2.14: 表示される文字: R

R [path]

「A」と同様、「R」はこのファイルが削除予定だということを示します。 「cvs commit」が実行されるとすぐに、このファイルはリポジトリから削除されます。

コード表示 2.15: 表示される文字: M

M [path]

このファイルはあなたによって変更されている、という意味です。 また、リポジトリにある変更がこのファイルにマージされた場合、 このファイルへのマージは成功したという意味でもあります。

コード表示 2.16: 表示される文字: C

C [path]

「C」の場合、そのファイルはコンフリクトしており、 「cvs commit」する前に手作業で修正する必要があることを示します。

コンフリクトの解消、その序章

ではいよいよ、コンフリクトの解消の仕方について見ていきます。 わたしは現在Gentoo Linuxプロジェクトにとても熱中しているんですが、 わたしたちはcvs.gentoo.orgで自分たちのCVSサーバを運営しています。 われわれ開発者たちは大半の時間を「gentoo-x86」モジュール内のソースをハックしまくることに費やします。 gentoo-x86モジュールの中には「ChangeLog」というファイルがあるんですが、 このファイルには(ご想像のとおり)リポジトリ内のファイルに関する大きな変更点に対する説明が蓄積されています。

コンフリクトの例

このChangeLogというファイルは、 開発者がメジャーな変更をCVSに対して行うとほぼ毎回書き替えられるので、 コンフリクトの一番良い例になります−−ではコンフリクトの例に行きますよ。 えーと、以下のような行をChangeLogの先頭に追加したとします:

コード表示 2.17: ChangeLogの内容

date 25 Feb 2001
 
This is the thing I added myself

それなのに、わたしがこの新しい3つの行のコミットに成功する前に、 別の開発者が以下のような行を同じChangeLogに追加してその変更をコミットしてしまったとします:

コード表示 2.18: もうひとつのChangeLogの内容

date 25 Feb 2001
 
This is the part added by another developer

コンフリクトの例、の続き

さて、わたしは(あなたがコミットの前に毎回行うように)cvs update -dPを実行するわけですが、 わたしたち双方がファイルの全く同じところに行を追加したため、 CVSはわたしのChangeLogのローカルコピーに対してもうひとりの開発者の変更をマージすることができません −− CVSにはどっちのバージョンを使用して良いかわかるはずがないですから。 というわけで、CVSは以下のようなエラーを表示します:

コード表示 2.19: CVSのエラー

RCS file: /home/cvsroot/gentoo-x86/ChangeLog,v
retrieving revision 1.362
retrieving revision 1.363
Merging differences between 1.362 and 1.363 into ChangeLog
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in ChangeLog
C ChangeLog

コンフリクトの解消、その1

なんてこった、コンフリクトしてるよ!  幸いなことに、コンフリクトの解消はカンタンです。 いつも使っているテキストエディタを起動して、 そのChangeLogファイルの先頭に以下のような文章があるのを見つけるわけです:

コード表示 2.20: ChangeLogのコンフリクト

<<<<<<< ChangeLog
date 25 Feb 2001
 
This is the thing I added myself
 
=======
date 25 Feb 2001
 
This is the part added by another developer
 
>>>>>>> 1.363

コンフリクトの解消、その2

いずれか一方を選んでしまうのではなく、CVSはChangeLogファイルに両方のバージョンを追加し、 問題のコンフリクト部分にすぐにわかるようなマークを付けて特別なセパレータで囲みます。 さてさて、その問題のマークされた部分がChangeLogでどうなっているべきであるかを考えて、 そこを書き替えるのはわたしの仕事です。 今回の場合、こっちのバージョンを使うのでもなく、 あっちのバージョンを使うのでもなく、両方を一緒にして文字を書き替えました:

コード表示 2.21: ChangeLogの内容

date 25 Feb 2001

This is the thing I added myself

This is the part added by another developer

さて、コンフリクトしていた部分をこれで良いだろうという文章に書き替え(もちろん「=======」やその他のマークも削除して)、 これでわたしは自分の変更を何の問題もなくCVSにコミットすることができるわけです。

コンフリクトを解消するコツ

コンフリクトしたファイルを編集する必要がある場合は、毎回、 確実にファイルの全体を調べてコンフリクトしている個所をすべて修正したことを確認してください。 直し忘れているコンフリクトがあるとCVSはそれが解消されるまではコミットさせてくれませんからね!  それから当然のことなんですが、CVSがコンフリクトしているファイルに付加した特別なマークを消すのも忘れないように。 コツをもうひとつ−−コンフリクトしているファイルを修正しようとして失敗、 その上(「あいたたたた!」)、不幸にも変更したファイルを保存してしまった、 そんなときは「.#filename.version」というファイルを探してください。 そこにあなたのバージョンのファイルのオリジナルコピーがあります。

ファイルを削除する

では、いよいよCVSの最後のスキル −− リポジトリからファイルを削除する方法 −− を学ぶときがやってきました。 ファイルの削除には2段階のプロセスを踏みます。 まず、ソース群の中から手元にある方のファイルを削除します。 その後、ファイルの削除に使用するcvs removeコマンドを実行します。

コード表示 2.22: ファイルを削除する

# rm myoldfile.c
# cvs remove myoldfile.c

ファイルを削除する、のつづき

そうすると、次にコミットが実行されるのに向けて、そのファイルは削除予約されます。 コミットされると同時に、そのファイルは正式に、レポジトリの最新バージョンから削除されます。 ですがCVSはそのファイルをどこかにやってしまうわけではなく、 将来再度必要になったときのために、 依然そのファイルの中身や履歴について完全な記録を持ち続けます。 これはCVSがあなたの価値あるソースコードを守ってくれる方法の、ほんのささいな例のひとつです。

cvs removeは再帰的に処理されます。つまり一連のファイルを削除しておいて、 それから親ディレクトリで「cvs remove」を他の引数無しで実行すれば大丈夫ということです。 こうすることで、削除された全ファイルが次のコミットのために削除フラグを付与されます。

ディレクトリを削除する

あるディレクトリ以下を全て削除してしまいたい場合は、以下の作業をすれば良いでしょう。 まず実際にそのディレクトリ内の全部のファイルを削除して「cvs remove」を実行します:

コード表示 2.23: ディレクトリを削除する

# rm *.c
# cvs remove

ディレクトリを削除する、のつづき

それから、コミットします:

コード表示 2.24: 変更をコミット

# cvs commit

お次はちょっと裏ワザ的な方法です。以下の作業をすることでディレクトリを削除します:

コード表示 2.25: ディレクトリを削除する

# cd ..
# cvs remove mydir
# rm -rf mydir

ディレクトリを削除したときは別途コッミトを実行する必要がないことに気が付きましたか? −− リポジトリに対するディレクトリの追加や削除はリアルタイムに行われるということです。

以上!

CVS入門は終了です −− このチュートリアルがお役に立てば幸いです。 CVSには、この入門編のチュートリアルではカバーできなった部分がもっともっとあります。 ですがありがたいことに、あなたのCVSに関する知識を増やしてくれる素晴しいリソースならたくさんあります:

このドキュメントについて

この記事のオリジナル版が最初に公開されたのはIBM developerWorks Linux Zoneでした。 この記事の所有権はWesttech Information Servicesに帰属します。 このドキュメントはその記事の更新版で、Gentoo Linuxドキュメントチームにより、 さまざまな改良を加えられています。



印刷

ページの更新日 October 7, 2003

この翻訳のオリジナルバージョンはすでにメンテナンスされていません。

要約: このチュートリアルでは読者のみなさんに、 世界中の開発者がソフトウェア開発に柔軟で協力的なやり方で使用している CVS −− Concurrent(並列) Versions System −− について紹介します。 CVSにあまり馴染みがない人たちのために、 このチュートリアルでは一般的なユーザーや開発者になったばかりの人がすぐについて行けるようにします。 何かのソフトウェアパッケージの最新のソースを「チェックアウト」するためにCVSを使うという人、 または一人前の開発者としてCVSを使い始めたい人、 どっちでも構いません、 このチュートリアルはそんなあなたたちのためのものです。

Daniel Robbins
Chief Architect

萩原佳明
翻訳

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.