miau's blog?

Visual SourceSafe 6.0 のバイナリファイル

以前のアイテムのコメント欄で、「VSS6 は NULL(\x00)を含むかどうかでバイナリファイルの判定やってるよ」と教えていただいたのですが。

Visual SourceSafe でのバイナリ ファイルの扱い

確かにそんなことが書いてますが、以前 EUC-JP のファイル(NULL とか含まない)を比較した時に「バイナリファイルに相違点があります」とか言われたことがありまして、なんか変だなと。
msdn はたまに記述間違ってることあるので、実際の動作を調べてみました。




調べた結果、確かに書いてる通りでした。
でも記述がすごくわかりにくかったので、ちょっと噛み砕きつつ書いておきます。

■ファイルの種類の自動検出

・VSS にファイルを追加する際、「詳細設定」からファイルの種類を選ぶことができる。

・規定値は「自動検出」だが、自動検出での判断手順は以下の通り。

 (1) 「オプション」→「ファイルの種類」でバイナリファイルとして登録している拡張子はバイナリファイル
 (2) (1) 以外で NULL(\x00)を含む場合はバイナリファイル
 (3) 上記以外はテキストファイル

・ファイルの種類の変更は、ファイルのプロパティ→種類から変更できる。
(ここで、プルダウンリストボックスのくせに選択肢がすべて表示されないバグ(?)があるので、
 カーソルキーを押下することで変更するしかないらしい)

要するに以前比較できなかった EUC-JP のファイルは、単純にバイナリファイルとして登録されていたので比較できなかった、ということらしい。


■バイナリファイルの挙動

バイナリファイルの挙動として

・ファイル比較の際、詳細情報が表示できない(「相違点があります」としか表示されない)

というものがあるんですが、不思議なことに改行コードの差異があっても「相違点なし」となります。
厳密に比較したい場合には使わないほうがいいかもしれません。

あと、「履歴の表示」→「レポート」→「詳細情報を含める」とかやった場合、バイナリファイルだと変更の内容までは教えてくれません。
この機能を使って毎月の作業工数を出してるので、バイナリファイルだとちょっと困ることになります。


■テキストファイルの挙動

改行コードが LF のファイルをチェックイン→取得すると、改行コードが CR+LF になってしまいます。
そのため、UNIX 系のソースを VSS で管理すると何かと面倒だったりするんですが。
(ローカルファイルが最新のものだと実際の取得は行われないのでさらに紛らわしいのですが)

詳細な動作は、

・ファイルの種類が「テキスト」の場合、チェックイン(or 登録)のタイミングで LF が CR+LF に置き換えられる

ということらしいです。
つまり、登録時にファイルの種類が「バイナリ」であれば、その後「テキスト」にしても改行コード LF としてファイルが取得できるわけです。


■運用方法

結局 UNIX 系のファイルに関しては
・改行コードを変更したくない→バイナリとして保存したい
・バイナリで保存してしまうと差分を表示できない→テキストで保存したい
というジレンマがあるわけですが。

ケースバイケースだと思うのですが、私の環境の場合は
(1) VSS から最新のソースを取得してリリースモジュールとする(月に数回)
(2) 履歴から詳細情報を出力して工数を算出する(月に一回)
(3) 特定のファイルの差分情報を調べる(適宜)
の 3 操作くらいが影響を受けます。

(3) に関しては比較の前に「テキスト」に変更すればいいだけなのでそれほど痛くないんですが、(1)、(2) の操作はすべてのファイルに対して種類を変更する必要があるわけで。
結局
・バイナリとして扱う拡張子に「*」を登録しておく
・通常は気軽に登録/変更が行えるようにバイナリにしておく
・一括でファイルの種類を変更するスクリプトか何かを作っておいて、工数算出の際は全部テキストにする
という運用にするのがいいような気がします。

どっちにしろ、登録済みのファイルはほとんどがテキストになってるから、全部バイナリに変換してチェックアウト→改行コード変更→チェックイン、としてやる必要がありそう。
面倒だから暇なときにやろう。


(2011-02-04 追記)

改行コードの扱いについて情報追加。VSS 2005 から(?)作業コピーの改行コードを強制できるようになっています。

Visual SourceSafe 2005 (VSS) 日本語版リリース | Cuore 技術 Blog

ちょっと改行コードの対応がマニュアルと違ってる気がして、
-G オプション (コマンド ライン)
によると -gr が CR(\r)、-gn が LF(\n)、-grn が CRLF(\r\n) みたいですね。

この機能も確か試したんですが、作業コピーが LF になるよう指定してもチェックインの動作は上記のとおりなので、リポジトリには手元のどこにも存在しない CRLF のファイルが格納されたりして、結局混乱を招いていた気がします。うろ覚えなので間違っていたらすみません。
posted at 15:14:45 on 2005-11-29 by miau - Category: General No Trackbacks - Permalink

TrackBack

このエントリにトラックバックはありません
現在トラックバックは受け付けていません。

Comments

katzchang wrote:

情報どうもです!

今回は「エンコードはUTF-8、改行はCR+LFという環境で、VSSを経由したファイルの改行コードの一部がCR+CR+LFになってしまう」というトラブルでした。

VSSに原因がありそう、ということであれば安心です。VSSをやめてもらえばいいわけですしw
2011-02-04 17:21:04

Add Comments

現在コメントは受け付けていません。
お手数ですが、 こちら のコメント欄にでも記載していただければと思います。