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

9. バイナリ・ファイルの扱い

最も普通の CVS の使用はテキスト・ファイルの保管です。テキスト・ファ イルでは、CVS はリビジョンをマージしたり、リビジョン間の違いを人 間が読める形式で表示したり、他の似たような操作をすることができます。し かし、これらの中のいくつかの機能を諦めることで、CVS はバイナリ・ ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ 画像の両方からなるウェブサイトを CVS で保管するかもしれません。

9.1 バイナリ・ファイルの問題  バイナリ・ファイルの問題の詳細
9.2 バイナリ・ファイルを保管する方法  保管方法


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

9.1 バイナリ・ファイルの問題

普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必 要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ せます。

バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。 例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ イルには、CVS は cvs diff コマンドでこの機能を提供します。 バイナリ・ファイルには、2つのリビジョンを取り出して、CVS の外部に あるプログラムで比較することができるでしょう (例えば、ワープロにはよく そのような機能があります)。もしそのようなツールがなければ、人に良いロ グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実 際にした変更が本当にそうしたいと思っている変更そのものであることを期待 しなければなりません。

バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。 CVS ではこれは2つの文脈で発生します。1つめは使用者が分離された作 業ディレクトリで変更をしたときです (see section 10. 複数の開発者)。2つ 目は `update -j' コマンドで明示的にマージしたときです (see section 5. 枝とマージ)。

テキスト・ファイルの場合は、CVS は独立になされた変更をマージでき、 変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、 CVS にできることは、せいぜい2つの違ったファイルのコピーを出して、 使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール があればそれを実行するかもしれません。使用者にマージをさせることは、主 に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して おり、エラーが発生する可能性が高いということに注意してください。

この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別 の作業ディレクトリによるマージを避けるためには、10. 複数の開発者 の独占取得 (ファイル占有) の議論を参照してください。枝によ るマージを避けるためには、枝の使用を制限してください。


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

9.2 バイナリ・ファイルを保管する方法

CVS でバイナリ・ファイルを保管する際の問題点が二つあります。 一つ目は、CVS がファイルを取り出す際に、 リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、 クライアント側のオペレーティングシステムに適した形式に変換する事です (例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり ます)。

二つ目の問題点は、キーワードと同じデータが 偶然バイナリ・ファイルに含まれる可能性がある事です (see section 12. キーワード置換)。 そのためキーワード展開を無効にする必要があります。

幾つかの CVS コマンドで `-kb' オプションを用いれば、 確実に行末変換とキーワード展開を止めることができます。

`-kb' フラグを用いて新しいファイルを登録する方法を、 以下に例示します:

 
$ echo '$Id$' > kotest
$ cvs add -kb -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest

ふと油断して `-kb' 無しでファイルを加えてしまった場合、 cvs admin コマンドを使用して正常な状態に戻す必要があります。 以下に例示します:

 
$ echo '$Id$' > kotest
$ cvs add -m"A test file" kotest
$ cvs ci -m"First checkin; contains a keyword" kotest
$ cvs admin -kb kotest
$ cvs update -A kotest
# For non-unix systems:
# Copy in a good copy of the file from outside CVS
$ cvs commit -m "make it binary" kotest

ファイル `kotest' を格納した時はファイルはバイナリ・ファイルとし ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ たからです。 `cvs admin -kb' コマンドでファイルの置換モードを設定しますが、 既にある作業コピーは変更してくれません。 行末を適切に処理する必要がある場合 (CVS のクライアントとして unix 以外のシステムを使用している場合) は、 上記の例に示した cvs commit コマンドのように、 新たにファイルのコピーを格納する必要があります。 Unix では、`cvs update -A' で十分です。 (デフォルトのキーワード置換モードを調べるためには cvs log を 使うことができ、作業コピーの置換方法を調べるためには cvs status を 使うことができます。)

ここで、`cvs admin -k' を用いて置換モードを変更しても、 この置換モードはバージョン管理されないことを認識しておいて下さい。 これは例えば古いリリースにテキスト・ファイルがあり、 新しいリリースに同じ名前のバイナリ・ファイルがあった場合、 バージョンによってテキストとバイナリを区別して取り出す方法を、 CVS が備えていないことを意味しています。 この問題を解決する方法は今のところありません。

cvs addcvs import を実行する際、 既定でバイナリとして扱うかどうかを、 ファイルの名前によって判断するように設定もできます。 例えば、ファイル名が `.exe' で終わるファイルを バイナリと判断するように設定できます。See section C.2 cvswrappers ファイル. 現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの 区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに 応じてかなり異なるであろうということです。


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

This document was generated by Yoshiki Hayashi on October, 13 2004 using texi2html