仕事でソース＆ドキュメント管理にVSSを使ってるんだが、ShiftJIS以外の文字コードのテキストファイルが壊れる(行末に全角文字があると改行コード(LFとかCRとかCR+LFとかまちまち？)が勝手に追加されたりする)ので、Subversionに挑戦中。

Subversionは2,3年前にも使いかけたことがあったんだけど、ちょうど仕事が変わっちゃってそのまま自然消滅。

当時は、Eclipse 2.x系にSubclipseを入れて色々試してたんだけど、時代は流れてEclipse 3.4 + Subversive (All in one Eclipse)でクライアント側の環境構築。

一方、VSSからのデータ移行はできないものかと調べてたら、svnimporterってのを発見。ちょっと試してみたら、日本語環境ではうまく動かない。ソースを落として見てみたら、VSS付属のクライアントコマンド(ss.exe)の出力をパースする部分が、英語表記でハードコーディングされていた。

そこで、ちょいちょいっと日本語表記に置き換えてみたら、なんとなく処理が進んだ。が、svnadmin loadで日本語のファイル名やフォルダ名を取り込むとこでエラーになっちゃう。UTF-8であるべきダンプファイルの文字列部分が文字化けしてる。

さらにソースを追ってみたら、どうもこのソース、UTF-8の扱いがおかしい。java.lang.Stringは、内部的にはUnicodeでデータを保持していて、標準出力やファイルに出力するときに、デフォルトではそのOSの標準文字コードに変換して出力され、出力ストリームを生成するときに指定すれば”UTF-8″や”EUC-JP”などの文字コードで出力できるはず。String.toByte(“文字コード”)でバイト列に変換したりとか。

なのに、String.toByte(“UTF-8”)でUTF-8にしたバイト列をさらにStringに格納してる。これって、UTF-8のバイト列をSJISと見なしてUnicodeとしてStringに格納しちゃうんじゃない？？英語圏はこれで問題起きないのかなあ？

というわけで、ダンプファイルを出力するPrintStreamを”UTF-8″で作成して、変に自前でStringをUTF-8変換しようとしてるところをスキップしてみたら…、文字化けは解消したけどやっぱりsvnadmin loadでコケる。チェックサムが合ってないようなバイト数が合ってないような。

自前UTF-8変換ではつじつまが合ってたバイト数のカウントが食い違ってしまっていた。Stringを変換せずにUnicodeのままで扱うようにしたので、バイト数をカウントするところで”UTF-8″に変換してバイト数をカウントするようにして、大成功！

これ、元ネタがオープンソースだから公開してもOKだよね。でも、会社からどうやってソースを持ち出そうかなあ。(T_T)

ていうか、常駐先って外のネットワークが見えないからスゲー不便。。。