コミット毎にファイル名のエンコーディングが異なってよいというのは、いろいろと面倒
そうです。 .hg/store/data/*.i の命名規則がえらいことになりそうだし。
個人的には、 EOL エクステンションのようなやり方がベターだと思います。設定を変えたら
どうするか、という問題は残りますが。
reviewboardというpythonで作られたソースコードレビューツールは、
指定する文字コードを1種類しか指定できないから一つのリポジトリに複数文字
コードが混在しているとエラー画面になっちゃうことがありまして、
それを個人的に直したものを仕事で使ってます。
reviewboard以外にtracも同じ問題あったんで直しちゃったりしましたが。
そんときの思想は、デフォルト文字コードutf8として、
とりあえずpythonレベルのunicode変換関数でエラー
になったらshift_jisを試す、
それでもだめならeucで試す、みたいに例外ハンドリング使った文字コード変換
しまくりでした。
mercurialもそれでいけそうですかね?
返信なければ試してみます。
1 つのリポジトリに 2 つ以上のファイル名エンコーディングがあれば、どちらかは
エラーになります。そのような状況でまともに運用することはほぼ不可能です。
例えば、 UTF-8 の "あ.txt" ("\xe3\x81\x82.txt") と CP932 の "あ.txt"
("\x82\xa0.txt") は、 Mercurial にとっては別ファイルです。これを Redmine が
同一視したらややこしいことになってしまう。
根本解決には、リポジトリのエンコーディングを統一する仕組みが必要ですが、
えらい大変だと思います。
ファイル名に日本語を使うことがないので、直す意欲も沸かないですし。
おっしゃるとおり大変なので、自分も諦めます。
お騒がせしました、返信された方ありがとうございます。
> ファイル名はおいておいて、
> ファイルの中身について、Trac に問題があるというのが驚きでした。
Tracはsvnが元で、それ以外がプラグインという形で後から追加されたので、
svnのようにvcsが正しいエンコーディングを教えてくれない場合は弱いですね。
bzr もsvnのようにエンコーディングなどの付加情報を管理する話は出ていますが、
今のところはまだサポートしていません。
hgやgitだと将来エンコーディング情報を管理する計画も無さそうですし、そういった
vcsのためにRedmineみたいな機能があると便利そう。要望だしておきます。
> コミットログは Mercurial は、かなり昔から 内部は UTF-8 なのですよね?
> Bazaar はいろいろややこしいようです。
Bazaarも「内部は」Unicodeです。(Bazaarの場合ファイル名もUnicodeなので
日本語ファイル名も問題ないです)
標準出力に出力するときにその環境に合わせてエンコードしているだけなので、
Bazaarの問題というよりはWindowsでも標準出力にUTF-8を期待しているRedmineとの
相性の問題です。(Tracなら何も問題ありません。)
Bazaarでも出力をUTF-8にするコマンドラインオプションが付いたら、Redmineとの
相性問題が解決されますし、そもそも現在でもxmlを使ってEclipseなどと連携できて
いたと思います。
--
INADA Naoki <songof...@gmail.com>
>> bzr もsvnのようにエンコーディングなどの付加情報を管理する話は出ていますが、
>> 今のところはまだサポートしていません。
>> hgやgitだと将来エンコーディング情報を管理する計画も無さそうですし、そういった
>> vcsのためにRedmineみたいな機能があると便利そう。要望だしておきます。
>
> MercurialのEOLエクステンションのプランの方には文字コード変換のことが
> 書いてありました。
> http://mercurial.selenic.com/wiki/EOLTranslationPlan#Content_filtering_hooks
content filtering はbzrにもありますが、これはブランチと作業ツリー間での変換のための
機能であり、ファイル一つ一つにエンコーディングやmime-typeのような情報を負荷する
versioned property とはちょっと違うものです。
とはいえ、versioned property が無いvcsではcontent filteringからエンコーディングに
関するヒントを得るのは良いアイデアですね。
> ということは、ここの
> http://www.redmine.org/issues/2664
> Bazaarでもこけるというのは、bzr log でのファイル名も、
> そのWindowsのロケールにエンコードされちゃっているという問題なのでしょうか?
はい、そうなります。
>> Bazaarでも出力をUTF-8にするコマンドラインオプションが付いたら、Redmineとの
>> 相性問題が解決されますし、そもそも現在でもxmlを使ってEclipseなどと連携できて
>> いたと思います。
>
> RedmineのMercurialアダプタはここで hg log を叩いて utf-8のXMLを得ています。
> http://www.redmine.org/projects/redmine/repository/entry/tags/0.9.4/lib/redmine/scm/adapters/mercurial_adapter.rb#L108
> SubversionアダプタもXMLを得ているので、これを元に作られたのかと解釈しています。
なるほど。
bzrの場合は、xml出力がプラグインという形になっていて、単体ではxml出力が利用できません。
しかし、Eclipse等のPythonではない外部プログラムでBazaarと連携する場合にはごく一般的に
利用されているプラグインなので、Redmineもできればこちらを使ったほうが良いと思います。
http://wiki.bazaar.canonical.com/XMLOutput
ちなみに、このプラグインはxmlrpc機能を持っていて、コマンドを起動するコストを削減して
IDE利用時のレスポンスを良くしています。
ただし、Redmineの場合はそんなに頻繁にコマンドを叩く必要はないと思うので、通常の
xml出力で充分だと思いますが。
> RedmineのBazaarアダプタは、sub-revision が取得できなかったり、
> http://www.redmine.org/issues/3559
> shared reposetories がサポートされてなかったり、
> http://www.redmine.org/issues/2799
> いろいろ大変なようです。
shared repositories って svn の branch と全く同じなのに何が大変なのか解りませんが、
sub-revision は難しいかもしれません。
hgやgitはメインラインとマージされたサブラインを対等に扱っているし、
逆にsvn関連のツールはサブラインを殆ど無視しちゃっているので、、、
--
INADA Naoki <songof...@gmail.com>
Adrianのコメントはパッチ作成をした人に対して
「英語環境(win32mbcsなし)でもテスト済みですか?」
と聞いてるのだと思います。つまり
「日本語環境だとこのパッチで上手くいくように作ってあるのであろうけれど、
このパッチを取り込むことで英語環境でなおかつwin32mbcsを
使っていないような英語圏のユーザには影響は出たりすることは
ありませんか?」
という確認を問いかけてるのではないかと思います。
--
Shun-ichi GOTO