日曜日, 8月 27, 2006

Visual SourceSafeでソースが壊れたけどセーフだった

版管理システム、これから使うならSubversion、でもCVSでもしぶしぶ使う。
ええ、使えというなら何でも使いますょ。

最近、さぼり気味の会社にふと行ってみたら、
参加していたプロジェクトのソースがVisual SourceSafeという版管理システムで
管理することになった直後だった。

げっ、Microsoftのツールかょ!!
いやな悪寒はしたけれども、仕事ならまぁ何でも使いますよ‥。

Visualと付くだけあって当然GUIベースで楽々‥操作なもので、
全然ドキュメント見なくて使える。使ったことある人からちょと聞けばね。

CVS使ったことあれば大雑把な概念のそのまた外枠くらいは似ても似つかぬ
わけじゃないので、だいたい把握できる、がやっぱりCVSと違って
色々とひっかかることがあった。

細かいことは置いといて。

ひとつ、やばい問題があった。文字コードの問題だ。
きた~! Microsoftきた~!

レポジトリにソースファイルを追加してみたところ、改行コードが化ける‥。
追加したものは文字コードがEUC-JP、改行コードはLFのもの。
VSSは「非常に賢い」ので、「自動で」文字コードを認識して適切に扱ってくれる。
ただし『EUCは扱えない』『改行コードはCRLFに変換する』。

EUC-JP-LFのものをレポジトリに入れると、
EUCの文字列をSJISだと解釈(変換ではない!)したうえで、
改行コードLFをすべてCRLFに変換する。
ところが、SJISじゃないのにSJISだと思って解釈するために、
ところどころLFを通常文字の2バイト目だと思ってしまい、読み飛ばす。
結果としてできるのは、改行コードがLFの行とCRLFの行が混じった
「何これ?」というファイル。

いやですねえ。なんとかしましょうょ。
でも困ったことに、いいですか、これでもほとんど何の問題もなかったのです!
これが恐ろしい‥。

まず、VSSで差分を見たりすると文字化けするけど、
どうせ誰もこの機能使わないみたいだし問題ない。
VSS上では問題ない。

gccでコンパイルするプロジェクトなんですが、gccはSJISだと困るけれども、
今回はEUCがSJISに直されたわけじゃないので、大丈夫。

改行コードがLFでなくCRLFになったとしてもgccは大丈夫、のはず~。
LF改行とCRLF改行が混じったソースでも、CRが単純に無視されてるなら
問題なし‥。うん、問題ない。

‥えっ? 問題なし?

私は(強いられたWindows環境では)EmacsクローンのMeadowを使っているが、
VSSリポジトリに入れたソースを持ってきてMeadowで開くと、
各行末に ^M が付いた見にくい「壊れたテキストファイル」が表示される。
よく探すと ^M が付いてない行が必ずひとつは見付かる。

つまりねえ‥Emacsは全部の行がCRLF改行なら全体をCRLF改行だと扱って
^Mは表示しないんだけど、ひとつでもCRなしのLF改行の行が見付かったら
全体をLF改行だとして扱って、CRは^Mで表示するんですよ。

この問題(問題が起きてないから問題ではない、か?)に気付いたのは私だけだった。
なぜなら、他の全員は秀丸エディタを使っていて、これがまた「非常に賢い」ために、
LFとCRLFが混在していても両方ただの改行と解釈して、^M とかそんな『変なもの』
は「見えないようにしてくれる」から。

飽くまでテキストエディタでありバイナリエディタではないので、
そういう方向もありだけど‥。
でもEmacsのほうが「正しい」。なぜなら
「オカシイものに気付かせてくれるから」。

改行コードは明らかに壊れている。潜在的に危険だ。
でも同時に、実際上は問題なくコンパイルは通るのだから
ソースコードは論理的には壊れていない‥。
ソースはセーフだったのだ。があああん!!
悪い意味でのプラグマティズム的には。
そして機械にとってはまったく純粋な意味で。
‥でも何かオカシイ‥。

コンピュータは言うのだ、「異常なし」、と。
でも私の心は‥この世界は危険だと感じる。

0 件のコメント: