コマンドライン CVS によるソースコード変更の寄稿

変更の CVS への寄稿

ファイルへの変更を共有リポジトリにコミットするには、次のコマンドを入力します。

cvs commit -m "ここに変更メッセージを入力" filename

ファイルへの変更に関する説明を含めなかった場合は、CVS がコミット操作を完了する前に、ファイル・エディタを実行して説明を加えるように要求されます。

ディレクトリとそのサブディレクトリにあるすべてのファイルへの変更をコミットするには、次のコマンドを入力します。

cd top_directory_to_commit
cvs commit -m "ここに変更メッセージを入力"

すべてのコミットは、自動的に記録され、プロジェクトの CVS メーリングリストに掲示されます。

ファイル/ディレクトリの追加

自分のワーキング・ディレクトリでファイルを作成し、編集した後でこの新しいファイルを CVS リポジトリに追加するには、次のコマンドを入力します。

cvs add filename

次に「CVS のファイル名コミット」コマンドを続けます。 最初にファイルを追加しなかった場合は、CVS はファイルを認識できません。

CVS への書き込み権限がある場合は、「cvs add」コマンドを使ってプロジェクトのソースツリーにサブディレクトリを追加できます。それから、「cvs move」コマンドを使って既存のファイルを新しいサブディレクトリに移動できます。

注意: CVS のディレクトリに名前を付けるときには、注意して行うようにしてください。 CVS のリポジトリには、さまざまなオペレーティングシステムを使用しているユーザがアクセスします。ディレクトリ名に使用した文字が読めないユーザがいるかもしれません。自分のオペレーティングシステムでは、.、~、/、\ やその他の文字をディレクトリ名として使用できる場合でも、ディレクトリにアクセスを必要とするほかのユーザがファイル構成スキーマを使用できない場合があります。ほかのユーザとの問題を避けるには、ディレクトリ名に次の文字のみを使用するようにします。

a〜z、A〜Z、0〜9、および _ (アンダースコア)

その他の文字を追加すると、ディレクトリ名がほかのオペレーティングシステムを使用するユーザが読めなくなることがあります。

ファイルの取り扱いについて

プロジェクトのリポジトリからのファイルのチェックアウトとリポジトリへのチェックインの間で、ファイルがどのようにプロジェクト環境やビルド・プロセスで使用されたかについては、CVS にはほとんど関係がありません。 これは、プロジェクトのオーナとプロジェクトに特有のその他の外部要因によって支配されます。

既存のファイルに変更を加える場合は、自分の選択したファイル・エディタを使ってローカルマシン上でこれらのファイルの作業用コピーを編集します。作業用コピーに加えた変更は、ファイルの変更したバージョンをチェックイン (cvs commit の実行) までは、プロジェクトのソース・リポジトリや他の開発者の作業には全く影響しません。

詳しくは、CVS が行わないことを参照してください。

ファイル形式について

CVS コマンドと操作についてこのドキュメントに記載されてている情報は、作業しているプロジェクト・ファイルがテキスト・ファイルであることを想定しています。CVS のバージョン管理にバイナリ・ファイルを含める可能性がある場合は、特別な問題がいくつかあります。

詳しくは、CVS のバイナリファイルのハンドリング を参照してください。

作業用ファイルとリポジトリファイルの日付を同じ日に維持する

ファイルの操作を行う前にファイルの状態を知りたい場合は、次のコマンドを使ってプロジェクトのリポジトリと日付が合っていないローカル・ディレクトリのファイル・リストを表示できます。

cvs -qn update

影響するディレクトリまたはサブディレクトリにあるファイルと現在のステータスが次のように示されます。

実際に更新を実行してワーキング・ディレクトリをリポジトリに同期させるには、次のコマンドを入力します。

cvs update

このコマンドにファイル名を追加して、個別のファイルを更新することもできます。

または、更新するときに新しいディレクトリを含めるには、次のコマンドを実行します。

cvs update -d

作業用ファイルと CVS リポジトリの比較

リポジトリの最新バージョンと自分の作業用コピーが同期しているかを見るもう 1 つの方法は、次のコマンドを使用する方法です。

cvstatus

または、個別のファイル・ステータスを確認するには、次のコマンドを使用します。

cvs status filename

この比較により、次のうちいずれかのメッセージが返されます。

Locally modified (ローカルで修正済み)
ファイルを編集しましたが、変更がコミットされていません。
Locally Added (ローカルで追加済み)
ファイルを追加しましたが、変更がコミットされていません。
Locally Removed (ローカルで削除済み)
「remove」を使ってファイルを削除しましたが、変更がコミットされていません。
Needs Checkout (チェックアウトが必要)
ほかのユーザが新しいリビジョンをリポジトリにコミットしています。このメッセージは操作を正確に表していないかもしれません。通常、新しいリビジョンを取得する場合には「チェックアウト」ではなく「更新」という用語を使用します。
Needs Patch (パッチが必要)
「チェックアウトが必要「と同じく、CVS サーバがファイル全体ではなくパッチを送信します。パッチまたはファイル全体を送信することは同じ結果となります。
Needs Merge (マージが必要)
ほかのユーザがより新しいリビジョンをリポジトリにコミットしました。さらに、自分もファイルに変更を加えています。
File had conflicts on merge (ファイルにマージ上の競合があります。)
これは、「ローカルで修正済み」と同じですが、前の「update」コマンドを実行すると競合が発生して、CVS が加えた変更を解決できません。 まず、コンフリクトの解決を実行しなければなりません。
不明
CVS はこのファイルに関して情報を持っていません。 たとえば、新しいファイルを作成したが、「cvs add」をまだ実行していないような場合に発生します。

一般的に、ファイルの変更をコミットする直前に、リポジトリと作業用ファイルが同期しているかを確認することをお勧めします。これは、異なるディレクトリからコミットしたり、自分がリポジトリからチェックアウトしたり最後に更新した後で、ほかの開発者が同じファイルに変更を加えた場合などの理由で、コミットが正しく実行できないことがあるためです。同じファイルの古いバージョンに対し、変更をコミットしようとすると、CVS がこれらをマージするときに競合が発生しやすくなります。このような状態でコミットしようとすると、CVS から「dying gasps」のメッセージが表示されることがあります。

ファイルのコピーとリポジトリの最新バージョンとの差を表示するには、次のコマンドを入力します。

cvs diff filename

プロジェクトレポジトリと自分の作業についての詳細

差をコミットする前に、ファイルのバージョンを比較する

自分の変更をコミットする前に、同じファイルにほかの開発者が加えた変更を表示したい場合があります。 たとえば、非常に複雑な変更をコミットしようとしている場合で、ほかの開発者の作業と競合が予想されるような場合です。

この場合は、別のファイル名で自分の作業用ファイルを保存しておきます (「 filename-new」など)。 それから、cvs updateコマンドを実行して、リポジトリの最新バージョンと自分のファイルを変更をコミットする前に比較します。 次の diff コマンドを使って、2 つのファイルを横に並べて比較することもできます。

diff -y filename filename-new

ほかの開発者の変更に自分の変更をマージする

「cvs update」 コマンドを実行することは、CVS にリポジトリの最新バージョンを自分の作業用コピーにマージすることと同じです。

しかし、最後に更新してからファイルに加えられた変更が、自分の変更と合わない場合があります。または、リポジトリのバージョン内で競合する変更を自分が加えたような場合もあります。 CVS は、更新してコミットする際に、このような競合をできるだけ自動的に解決しようと試みますが、すべてを解決できない場合があります。この場合、ファイル内の競合は、手作業で解決しなければなりません。

マージする際のコンフリクトの解消

マージ・コンフリクトを解決するには、ファイル・エディタでファイルを開きます。>>>>>> and <<<<<<<<でマークされている行やセクションを探します。 CVS がコンフリクトを解決できない場合は、両バージョンに影響する行やセクションをファイルに含めます。最新のバージョンが通常先に挿入されます。コンフリクトを解消する作業は、不必要な行とコンフリクトの記号やリビジョン番号などを含む行を削除することです。 それから、ファイルを保存して再度コミットします。

リビジョン履歴と復旧

cvs logコマンドを使ってファイルの変更履歴を表示すること以外に、復旧プロセスを使って以前のファイル・リビジョンを最新のバージョンとして実際に復旧させることができます(「リポジトリのヘッド」に復元されます)。 これは、いかなる理由があるとしても、ファイルを以前のバージョンに戻す必要がある場合に便利です。開発プロジェクトに壊れたビルドやほかの問題がある場合は、これは最も便利で強力なバージョン管理機能になります。

>注意: 「リビジョン」と「バージョン」の違いを混同することがあります。 リビジョンは、個々のファイルの特定のアップデートで、リビジョン番号は 1.1、1.2、1.3 などとなります。 「cvs log filename」コマンドを実行すると、特定のファイルのリビジョン番号がすべて表示されます。一方、バージョンは、ファイル・リビジョンのセットで、特定の時点でタグ付けされ名前が付けられます。バージョンはファイルのリビジョンと同様に名前が付けられるため、混同しやすくなっています (1.0、1.1、1.2 など)。しかし、バージョンはこの方法で名前を付ける必要はありません。プロジェクトオーナが指定した任意の文字列や、異なる番号スキームを使用できます。

まず、復旧を行う前に、現在のリポジトリ・ヘッドにあるファイル・バージョンと復旧しようとしているバージョン間の差を確認することをお勧めします。これには、次のコマンドを使用します。

cvs diff -c -r version# -r version# filename

これにより、復旧しようとする前に、2 つのファイルを比較できます。 2 つのバージョンを区別できる限り、このコマンドの結果は致命的なものにはなりません。

復旧に使用するコマンドには、バージョン番号のルールに厳しく従うことが必要です。最新のバージョンから以前のバージョンに復旧するには、次のコマンドを入力します。

cvs update -j later_version# -j earlier_version# filename

復旧には、複数の方法があるため、次の項目も参照してください:
復旧についての詳細
リビジョン履歴についての詳細

復旧は、「スティッキー・タグ」エラーを招く場合があるということにも注意してください。これは、次の更新コマンドに特別なスイッチを使って解決できます。

cvs update -dAP

(スティッキ−タグエラーとは?)

より詳しい CVS のヘルプ: コマンドライン CVS を使ったプロジェクトファイルとディレクトリの管理