[mercurial-ja:392] TortoiseHg SJISダメ文字ファイル名の Windows icon overlay

[Toshi MARUYAMA]

はじめまして。まるやまと申します。

Windows で日本語ファイル名を試す機会があったので、試してみました。

Mercurial と連携するツール
http://mercurial.selenic.com/wiki/OtherTools
に入っているので、ここに載せて良いんですね。
ここです。
http://www.redmine.org/issues/5408
西原さんお世話になっております。

現状は、このグループのここに書いてある通りのようです。
http://groups.google.com/group/mercurial-ja/browse_thread/thread/2a25b275f631cea3#
やっぱり、SJISダメ文字ファイル名のアイコンオーバーレイがだめのようです。

UNICODE 化のプランがあるようですが、
http://bitbucket.org/tortoisehg/stable/wiki/developers/NewShellExtensionPlan
少しいじれば何とかなりそうだったので、何とかしてみました。
http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overlay-of-files-which-contain-0x5c-backslash-in-file
'\\' で grep かけて、それらしき所で、UNICODE に変換して、もとに戻しています。

その後、TortoiseHg の stable に非常に気になる commit が入っています。
http://bitbucket.org/tortoisehg/stable/changeset/e339e23df70c

TortoiseHg の方向性がなかなか見づらいので、どうしたら良いでしょうか。

以上、よろしくお願いします。

--
from Mercurial 日本語コミュニティ <mercur...@googlegroups.com>
※ ヘルプ表示は http://groups.google.com/group/mercurial-ja?hl=ja

[Yuki KODAMA]

2010/5/22 Toshi MARUYAMA <marut...@yahoo.co.jp>:

> はじめまして。まるやまと申します。
>
> Windows で日本語ファイル名を試す機会があったので、試してみました。
>
> Mercurial と連携するツール
> http://mercurial.selenic.com/wiki/OtherTools
> に入っているので、ここに載せて良いんですね。
> ここです。
> http://www.redmine.org/issues/5408
> 西原さんお世話になっております。
>
> 現状は、このグループのここに書いてある通りのようです。
> http://groups.google.com/group/mercurial-ja/browse_thread/thread/2a25b275f631cea3#
> やっぱり、SJISダメ文字ファイル名のアイコンオーバーレイがだめのようです。
>
> UNICODE 化のプランがあるようですが、
> http://bitbucket.org/tortoisehg/stable/wiki/developers/NewShellExtensionPlan
> 少しいじれば何とかなりそうだったので、何とかしてみました。
> http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overlay-of-files-which-contain-0x5c-backslash-in-file
> '\\' で grep かけて、それらしき所で、UNICODE に変換して、もとに戻しています。
>
> その後、TortoiseHg の stable に非常に気になる commit が入っています。
> http://bitbucket.org/tortoisehg/stable/changeset/e339e23df70c
>
> TortoiseHg の方向性がなかなか見づらいので、どうしたら良いでしょうか。
>
> 以上、よろしくお願いします。

パッチありがとうございます。
シェル拡張のUnicode化はあのまま進んでいないため助かります。

さて、2つ目の気になる変更ですが、完全に見過していました。
この変更は日本語のFile Patternsフィルタリングを完全に殺しますね。
そもそも、GTK+の上で入力された文字列はすべてUTF-8なので、
Mercurialに渡す前にローカルのエンコーディングに変換する必要があります。

hglib.fromutf()は常にMercurialが使用するbyte stringに変換してくれると思っていた
のですが、Henrikの言い方だとそうでないケースがあるということでしょうか？

今さっきMLに投稿されたパッチのメールに返信してみたので、
その反応を待ちます。

--
Yuki KODAMA

[Shun-ichi Goto]

2010年5月24日12:47 Yuki KODAMA <yuki....@gmail.com>:
> hglib.fromutf()は常にMercurialが使用するbyte stringに変換してくれると思っていた
> のですが、Henrikの言い方だとそうでないケースがあるということでしょうか？

mercurial は渡されたバイト列を覚えるだけなので、
locale の違う環境で互いに違うエンコーディングでコミットされることに対して
防御出来ないし、それぞれのエンコーディングを覚えることもしないため、
結局正しいエンコーディングというものが分からない(mercurialが伝達しない)という
ことではないでしょうか。

たとえば utf-8 なUNIX環境で日本語ファイル名をコミットして、そのリポジトリを
日本語Windowsでクローンした場合、local encoding != utf-8 な状態となります。
さらにそのWindowsで日本語ファイル名をコミットしちゃうとsjisとutf-8の混在する
リポジトリが出来上がってしまいます。
こうなると現状ではほとんどハンドリング不可能になってしまいます。

こういう事態が簡単に起き得ることをMattはあまり問題視していないようで困るのですが。
できればmanifestにencoding情報を付加するなどの対策が欲しいところ。

--
Shun-ichi GOTO

[Yuya Nishihara]

西原です、こんばんは。

Shun-ichi Goto wrote:
> 2010年5月24日12:47 Yuki KODAMA <yuki....@gmail.com>:
> > hglib.fromutf()は常にMercurialが使用するbyte stringに変換してくれると思っていた
> > のですが、Henrikの言い方だとそうでないケースがあるということでしょうか？
>
> mercurial は渡されたバイト列を覚えるだけなので、
> locale の違う環境で互いに違うエンコーディングでコミットされることに対して
> 防御出来ないし、それぞれのエンコーディングを覚えることもしないため、
> 結局正しいエンコーディングというものが分からない(mercurialが伝達しない)という
> ことではないでしょうか。

欧米だと iso-8859-n と utf-8 が混ざっててもそれなりに見えちゃうんでしょうかね。
アルファベットが共通だから。

> こういう事態が簡単に起き得ることをMattはあまり問題視していないようで困るのですが。
> できればmanifestにencoding情報を付加するなどの対策が欲しいところ。

小手先の対処であれば、 TortoiseHg にファイル名エンコーディングの設定を足せば
いいかもしれません。選択肢は「ノータッチ, ロケール, utf-8, ...」で。
GUI とやり取りする箇所で変換をかける。

[Toshi MARUYAMA]

まるやまです。

せっかくなので、テストリポジトリを Bitbucket に上げてみました。
http://bitbucket.org/marutosi/nihongo
まさかの、SJISファイル名が見れるのですが、何かおかしいようです。

On 5月24日, 午後12:47, Yuki KODAMA <yuki.kod...@gmail.com> wrote:

> 2010/5/22 Toshi MARUYAMA <marutosi...@yahoo.co.jp>:
>
> > UNICODE 化のプランがあるようですが、
> >http://bitbucket.org/tortoisehg/stable/wiki/developers/NewShellExtens...
> > 少しいじれば何とかなりそうだったので、何とかしてみました。
>
> パッチありがとうございます。
> シェル拡張のUnicode化はあのまま進んでいないため助かります。

このパッチをあてたことが前提なのですが、
エクスプローラ右クリックで「追加」などメニューが表示されるようになったのですが、
ダメ文字が入っているファイルの挙動がおかしいです。
デバッガによると、「追加」の場合、
"C:\Program Files\TortoiseHg\\hgtk.exe" --nofork add --listfile
"tempfile"
を実行しているようです。

あと、PyQtの現在最新のものを、Windowsでこのリポジトリに対して
実行すると、不思議な文字化けをします。
イメージをここに上げました。
http://bitbucket.org/marutosi/nihongo/src/tip/thg.png
"View image"をクリックすると見れます。

以上、よろしくお願いします。

[Toshi MARUYAMA]

まるやまです。

On 5月24日, 午後11:16, Yuya Nishihara <you...@gmail.com> wrote:
> 西原です、こんばんは。
>
> Shun-ichi Goto wrote:

> > 2010年5月24日12:47 Yuki KODAMA <yuki.kod...@gmail.com>:

> > > hglib.fromutf()は常にMercurialが使用するbyte stringに変換してくれると思っていた
> > > のですが、Henrikの言い方だとそうでないケースがあるということでしょうか？
>
> > mercurial は渡されたバイト列を覚えるだけなので、
> > locale の違う環境で互いに違うエンコーディングでコミットされることに対して
> > 防御出来ないし、それぞれのエンコーディングを覚えることもしないため、
> > 結局正しいエンコーディングというものが分からない(mercurialが伝達しない)という
> > ことではないでしょうか。
>
> 欧米だと iso-8859-n と utf-8 が混ざっててもそれなりに見えちゃうんでしょうかね。
> アルファベットが共通だから。
>
> > こういう事態が簡単に起き得ることをMattはあまり問題視していないようで困るのですが。
> > できればmanifestにencoding情報を付加するなどの対策が欲しいところ。
>
> 小手先の対処であれば、 TortoiseHg にファイル名エンコーディングの設定を足せば
> いいかもしれません。選択肢は「ノータッチ, ロケール, utf-8, ...」で。
> GUI とやり取りする箇所で変換をかける。
>

hgsubversionが、extraを使っているようですが、このextraを使えないでしょうか？
commitをラップして、extraに実行時のファイル名エンコードを付加する。
pushでマルチヘッドになる場合警告が出るように、違うエンコードでコミットする場合、
警告を出す、という具合に。

[Yuya Nishihara]

西原です。こんばんは。

コミット毎にファイル名のエンコーディングが異なってよいというのは、いろいろと面倒
そうです。 .hg/store/data/*.i の命名規則がえらいことになりそうだし。

個人的には、 EOL エクステンションのようなやり方がベターだと思います。設定を変えたら
どうするか、という問題は残りますが。

[Toshi MARUYAMA]

まるやまです。

EOLエクステンションのWikiがあがっていたのでざっと読んでみました。
http://mercurial.selenic.com/wiki/EolExtension

ポイントはこんなもんでしょうか。
・.hgeol というファイルを作って、その中に設定を指定する
・リポジトリには LF で保存するのがデフォルトだが、別のものも指定もできる

これをファイル名エンコーディングにあてはめるとすると、以下のようになるんでしょうか。
・.hg_filename_encoding みたいな名前のファイルを用意する
・すでに SJIS で入れてしまった場合は filename_encoding = sjis と指定する
・新規やデフォルトは ノータッチ, utf-8 ？

あと、update はロケール依存で良いかと思ったのですが、
私が何年か前に Subversion を触ったときに Unix / Linux で checkout 時のロケールに
依存してしまうのが不便に感じたのと、波線かダッシュでトラブった記憶があるので、
どうすれば良いのか分かりません。

[tomoyuki.kaminishi]

ども、トモです。

reviewboardというpythonで作られたソースコードレビューツールは、
指定する文字コードを1種類しか指定できないから一つのリポジトリに複数文字
コードが混在しているとエラー画面になっちゃうことがありまして、
それを個人的に直したものを仕事で使ってます。
reviewboard以外にtracも同じ問題あったんで直しちゃったりしましたが。

そんときの思想は、デフォルト文字コードutf8として、
とりあえずpythonレベルのunicode変換関数でエラー
になったらshift_jisを試す、
それでもだめならeucで試す、みたいに例外ハンドリング使った文字コード変換
しまくりでした。

mercurialもそれでいけそうですかね？

返信なければ試してみます。

[Toshi MARUYAMA]

まるやまです。

On 6月4日, 午前2:06, "tomoyuki.kaminishi" <god.eat.go...@gmail.com> wrote:
> ども、トモです。
>
> reviewboardというpythonで作られたソースコードレビューツールは、
> 指定する文字コードを1種類しか指定できないから一つのリポジトリに複数文字
> コードが混在しているとエラー画面になっちゃうことがありまして、
> それを個人的に直したものを仕事で使ってます。
> reviewboard以外にtracも同じ問題あったんで直しちゃったりしましたが。
>
> そんときの思想は、デフォルト文字コードutf8として、
> とりあえずpythonレベルのunicode変換関数でエラー
> になったらshift_jisを試す、
> それでもだめならeucで試す、みたいに例外ハンドリング使った文字コード変換
> しまくりでした。
>
> mercurialもそれでいけそうですかね？
>
> 返信なければ試してみます。
>

このエラーになるという VCS は何ですか？
reviewboard を存じないので分かりませんが、
もし、CVS, git であれば、同じ要領でいけると思います。


TO: 西原さん

西原さんの Redmine のこのパッチも同じ問題があるのでしょうか？
http://www.redmine.org/issues/2664

Linux 上なら気軽に複数エンコードファイル名リポジトリが
作れるのでやってみましょうか？

[Yuya Nishihara]

Toshi MARUYAMA wrote:
> On 6月4日, 午前2:06, "tomoyuki.kaminishi" <god.eat.go...@gmail.com> wrote:
> > reviewboardというpythonで作られたソースコードレビューツールは、
> > 指定する文字コードを1種類しか指定できないから一つのリポジトリに複数文字
> > コードが混在しているとエラー画面になっちゃうことがありまして、
> > それを個人的に直したものを仕事で使ってます。
> > reviewboard以外にtracも同じ問題あったんで直しちゃったりしましたが。
> >
> > そんときの思想は、デフォルト文字コードutf8として、
> > とりあえずpythonレベルのunicode変換関数でエラー
> > になったらshift_jisを試す、
> > それでもだめならeucで試す、みたいに例外ハンドリング使った文字コード変換
> > しまくりでした。

...

> 西原さんの Redmine のこのパッチも同じ問題があるのでしょうか？
> http://www.redmine.org/issues/2664

1 つのリポジトリに 2 つ以上のファイル名エンコーディングがあれば、どちらかは
エラーになります。そのような状況でまともに運用することはほぼ不可能です。

例えば、 UTF-8 の "あ.txt" ("\xe3\x81\x82.txt") と CP932 の "あ.txt"
("\x82\xa0.txt") は、 Mercurial にとっては別ファイルです。これを Redmine が
同一視したらややこしいことになってしまう。

根本解決には、リポジトリのエンコーディングを統一する仕組みが必要ですが、
えらい大変だと思います。
ファイル名に日本語を使うことがないので、直す意欲も沸かないですし。

[tomoyuki.kaminishi]

ども、トモです。
メールタイトルと返信内容見直しまして、自分が勘違いしてました。
ファイルの内容の文字コード混在だと思ったのですが、ファイル名、なのですね。

おっしゃるとおり大変なので、自分も諦めます。
お騒がせしました、返信された方ありがとうございます。

[Toshi MARUYAMA]

まるやまです。

On 6月4日, 午後9:14, "tomoyuki.kaminishi" <god.eat.go...@gmail.com> wrote:
> ども、トモです。
> メールタイトルと返信内容見直しまして、自分が勘違いしてました。
> ファイルの内容の文字コード混在だと思ったのですが、ファイル名、なのですね。
>
> おっしゃるとおり大変なので、自分も諦めます。
> お騒がせしました、返信された方ありがとうございます。
>

いやいや、VCS,SCM と連携するツールでは文字コードは悩ましいものですから。
文字コードが絡むのは、ファイル名、ファイルの中身、コミットログ、コミットユーザ
があると思います。

ファイル名はおいておいて、
ファイルの中身について、Trac に問題があるというのが驚きでした。
Redmine は文字コードを複数設定出来た気がしたので、さくっとテストしてみました。
やっぱりできました。
http://bitbucket.org/marutosi/redmine-test-mercurial-repository/raw/b0002deb2185/images/redmine-repo-encoding-setting.png

コミットログは Mercurial は、かなり昔から 内部は UTF-8 なのですよね？
Bazaar はいろいろややこしいようです。

Missing characters from repository comments
http://www.redmine.org/issues/5578
want an option to set the output encoding, especially on win32
https://bugs.launchpad.net/bzr/+bug/340394

Mercurial も HGENCODING で制御できたんでしたっけ？

コミットユーザは良く分かっていないです。

[INADA Naoki]

稲田です。
脱線ですが、bzrとtracについて補足を。

> ファイル名はおいておいて、
> ファイルの中身について、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>

[Toshi MARUYAMA]

まるやまです。

On 6月5日, 午前12:40, INADA Naoki <songofaca...@gmail.com> wrote:
> 稲田です。
> 脱線ですが、bzrとtracについて補足を。
>
> > ファイル名はおいておいて、
> > ファイルの中身について、Trac に問題があるというのが驚きでした。
>
> Tracはsvnが元で、それ以外がプラグインという形で後から追加されたので、
> svnのようにvcsが正しいエンコーディングを教えてくれない場合は弱いですね。

RedmineもSubversionが元だったようです。
ただRedmineはプラグインでは無くビルドインで、
かなり徹底した抽象化がされています。
ビルドインのため、メンテナンスができないという理由で、
Perforceサポートが、はねられちゃっています。
http://www.redmine.org/issues/339#note-50

> bzr もsvnのようにエンコーディングなどの付加情報を管理する話は出ていますが、
> 今のところはまだサポートしていません。
> hgやgitだと将来エンコーディング情報を管理する計画も無さそうですし、そういった
> vcsのためにRedmineみたいな機能があると便利そう。要望だしておきます。

MercurialのEOLエクステンションのプランの方には文字コード変換のことが
書いてありました。
http://mercurial.selenic.com/wiki/EOLTranslationPlan#Content_filtering_hooks

> > コミットログは Mercurial は、かなり昔から 内部は UTF-8 なのですよね？
> > Bazaar はいろいろややこしいようです。
>
> Bazaarも「内部は」Unicodeです。（Bazaarの場合ファイル名もUnicodeなので
> 日本語ファイル名も問題ないです）
> 標準出力に出力するときにその環境に合わせてエンコードしているだけなので、
> Bazaarの問題というよりはWindowsでも標準出力にUTF-8を期待しているRedmineとの
> 相性の問題です。（Tracなら何も問題ありません。）

ということは、ここの
http://www.redmine.org/issues/2664
Bazaarでもこけるというのは、bzr log でのファイル名も、
そのWindowsのロケールにエンコードされちゃっているという問題なのでしょうか？
Redmineは、ここで bzr log を叩いています。
http://www.redmine.org/projects/redmine/repository/entry/tags/0.9.4/lib/redmine/scm/adapters/bazaar_adapter.rb#L80

> 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を得ているので、これを元に作られたのかと解釈しています。

RedmineのBazaarアダプタは、sub-revision が取得できなかったり、
http://www.redmine.org/issues/3559
shared reposetories がサポートされてなかったり、
http://www.redmine.org/issues/2799
いろいろ大変なようです。

[INADA Naoki]

稲田です。

>> 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>

[Toshi MARUYAMA]

まるやまです。

On 5月24日, 午後12:47, Yuki KODAMA <yuki.kod...@gmail.com> wrote:
> 2010/5/22 Toshi MARUYAMA <marutosi...@yahoo.co.jp>:

(snip)
>
> > 現状は、このグループのここに書いてある通りのようです。
> >http://groups.google.com/group/mercurial-ja/browse_thread/thread/2a25...
> > やっぱり、SJISダメ文字ファイル名のアイコンオーバーレイがだめのようです。
>
> > UNICODE 化のプランがあるようですが、
> >http://bitbucket.org/tortoisehg/stable/wiki/developers/NewShellExtens...
> > 少しいじれば何とかなりそうだったので、何とかしてみました。
> >http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overla...

> > '\\' で grep かけて、それらしき所で、UNICODE に変換して、もとに戻しています。
>
> > その後、TortoiseHg の stable に非常に気になる commit が入っています。
> >http://bitbucket.org/tortoisehg/stable/changeset/e339e23df70c
>
> > TortoiseHg の方向性がなかなか見づらいので、どうしたら良いでしょうか。
>
> > 以上、よろしくお願いします。
>
> パッチありがとうございます。
> シェル拡張のUnicode化はあのまま進んでいないため助かります。
>

このissueに対するフォローが入ったのですが、Win32mbcs extension が絡むのか否か、
誰に対する問いかけなのか、わからないのですがどうすれば良いでしょうか？
http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overlay-of-files-which-contain-0x5c-backslash-in-file

[Shun-ichi Goto]

2010年6月13日17:32 Toshi MARUYAMA <marut...@yahoo.co.jp>:

> このissueに対するフォローが入ったのですが、Win32mbcs extension が絡むのか否か、
> 誰に対する問いかけなのか、わからないのですがどうすれば良いでしょうか？
> http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overlay-of-files-which-contain-0x5c-backslash-in-file

Adrianのコメントはパッチ作成をした人に対して
「英語環境(win32mbcsなし)でもテスト済みですか？」
と聞いてるのだと思います。つまり

「日本語環境だとこのパッチで上手くいくように作ってあるのであろうけれど、
このパッチを取り込むことで英語環境でなおかつwin32mbcsを
使っていないような英語圏のユーザには影響は出たりすることは
ありませんか？」

という確認を問いかけてるのではないかと思います。

--
Shun-ichi GOTO

[Toshi MARUYAMA]

まるやまです。

On 6月14日, 午前1:01, Shun-ichi Goto <shunichi.g...@gmail.com> wrote:
> 2010年6月13日17:32 Toshi MARUYAMA <marutosi...@yahoo.co.jp>:

>
> > このissueに対するフォローが入ったのですが、Win32mbcs extension が絡むのか否か、
> > 誰に対する問いかけなのか、わからないのですがどうすれば良いでしょうか？
> >http://bitbucket.org/tortoisehg/stable/issue/1241/windows-icon-overlay-of-files-which-contain-0x5c-backslash-in-file
>
> Adrianのコメントはパッチ作成をした人に対して
> 「英語環境(win32mbcsなし)でもテスト済みですか？」
> と聞いてるのだと思います。つまり
>
> 「日本語環境だとこのパッチで上手くいくように作ってあるのであろうけれど、
> このパッチを取り込むことで英語環境でなおかつwin32mbcsを
> 使っていないような英語圏のユーザには影響は出たりすることは
> ありませんか？」
>
> という確認を問いかけてるのではないかと思います。
>

回答ありがとうございます。

一応、日本語でしかテストしていないということを書いて、
関連すると思われるissueをあげておきました。

Windowsはまだ日本語版という売り方をしているのですよね？
NTFSの内部はUnicodeだと思いましたし(FATは8.3形式が違った気が)、
日本語Windowsでも、コントロールパネルを変えれば、
がらっと見栄えが変わった気がしたんですが。

[Toshi MARUYAMA]

まるやまです。

やっぱり気になるので、このグループにメールしておきます。

On 5月24日, 午後11:16, Yuya Nishihara <you...@gmail.com> wrote:

(snip)

> 小手先の対処であれば、 TortoiseHg にファイル名エンコーディングの設定を足せば
> いいかもしれません。選択肢は「ノータッチ, ロケール, utf-8, ...」で。
> GUI とやり取りする箇所で変換をかける。

tortoisehg.fsencodings という設定が追加されて、
PyGTK の方の default にコミットが入って、stable にもマージされましたね。
http://bitbucket.org/tortoisehg/stable/changeset/fc3d0978e38b
PyQt の方はまだ見ていません。