Mercurial 1.9 is released !
フジワラ
Mercurial 1.9 がリリースされました。
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_1.9_.282011-07-01.29
今回はメジャーバージョンアップでしたので、かなり多くの変更が
取り込まれていますね。
Toru Uetani
早速リリースされたTortoiseHg 2.1 を使ってみたんですが、
日本語ファイル名の扱いに問題があるようです。
TortoiseHg 2.0.5 では問題なくupdateできますが、2.1だとupdateに失敗します。
問題を再現できるように、bitbucketにリポジトリを作成しました。
https://bitbucket.org/toruuetani/thg-win32mbcs-bug
win32mbcsを有効にした状態でリポジトリを作成して、
TortoiseHg 2.1 でupdateすると以下のようなエラーが出ます。
最初win32mbcsが効いてないのかと思いましたが、2.0.5と2.1の両方で
win32mbcs有効・無効を切り替えても動作に影響がありませんでした。
同じような問題が発生している方はいませんか？
% hg update --repository D:\Work\thg --verbose --config
ui.merge=internal:fail --rev 1 --clean
resolving manifests
getting ソ連表.txt
getting 画面設計__同期－サブメニュー.txt
中止: filename contains '|', which is reserved on Windows:
'\x89\xe6\x96\xca\x90\xdd\x8cv__\x93\xaf\x8a\xfa\x81|\x83T\x83u\x83\x81\x83j\x83\x85\x81[.txt'
[command returned code 255 Tue Jul 05 22:57:38 2011]
Katsunori FUJIWARA
2011年7月5日23:07 Toru Uetani <toru....@gmail.com>:
以下の改善に起因する問題だと思われます。
add: introduce a warning message for non-portable filenames
mercurial.util.checkwinfilename における文字判定処理が、
MBCS なファイル名を UTF-8 化せずに実施しているのが原因でしょうね。
今、手元に Windows バイナリ版が無いので、ソースビルド版@Cygwin での
動作確認ですが、ファイル追加の際に警告されました。
＃ clone における working directory update では特に警告は無し＠cygwin 版
win32mbcs.py 中の funcs 文字列に列挙されている対象関数に
mercurial.util.checkwinfilename を追加すれば回避できると思うのですが、
この認識であってますかね？ ＞ Goto さん
以下、パッチイメージ。
=========
diff -r 8dab23af7c51 hgext/win32mbcs.py
--- a/hgext/win32mbcs.py Wed Jul 06 11:21:33 2011 +0900
+++ b/hgext/win32mbcs.py Wed Jul 06 11:29:34 2011 +0900
@@ -129,7 +129,8 @@
funcs = '''os.path.join os.path.split os.path.splitext
os.path.splitunc os.path.normpath os.path.normcase os.makedirs
mercurial.util.endswithsep mercurial.util.splitpath mercurial.util.checkcase
- mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath'''
+ mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath
+ mercurial.util.checkwinfilename'''
# codec and alias names of sjis and big5 to be faked.
problematic_encodings = '''big5 big5-tw csbig5 big5hkscs big5-hkscs
========
Windows 環境以外であれば、ui.portablefilenames を warn ないし ignore に
することで回避できるようですが、Windows 環境の場合は問答無用で
abort 設定ルートを通る模様です。
この手の問題を回避するために、ファイル名に関する処理／判定系の追加／更新に
上手く追従できるような仕組みが欲しいですねぇ ＞ mercurial-devel
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Shun-ichi Goto
> win32mbcs.py 中の funcs 文字列に列挙されている対象関数に
> mercurial.util.checkwinfilename を追加すれば回避できると思うのですが、
> この認識であってますかね？ ＞ Goto さん
実際にはエイリアスである util.checkosfilename の方をラップしないとダメですね。
そういうわけで藤原さんのパッチではなく、以下のパッチを使用してみてください。>all
-------------------(cut here)-----------------------
diff -r 4b58d9402c43 hgext/win32mbcs.py
--- a/hgext/win32mbcs.py Thu Dec 09 13:40:28 2010 +0900
+++ b/hgext/win32mbcs.py Wed Jul 06 12:32:01 2011 +0900
@@ -129,7 +129,8 @@
funcs = '''os.path.join os.path.split os.path.splitext
os.path.splitunc os.path.normpath os.path.normcase os.makedirs
mercurial.util.endswithsep mercurial.util.splitpath mercurial.util.checkcase
- mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath'''
+ mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath
+ mercurial.util.checkosfilename'''
# codec and alias names of sjis and big5 to be faked.
problematic_encodings = '''big5 big5-tw csbig5 big5hkscs big5-hkscs
-------------------(cut here)-----------------------
それとcheckosfilename()ではなくcheckwinfilename()を直接使ってる箇所が scmutil に
あるのですが、そのあたりを確認して、checkwinfilenameもラップすべきか判断してから
hg-devに投げようと思います。
--
Shun-ichi GOTO
Yuya Nishihara
On 7月6日, 午後12:34, Shun-ichi Goto <shunichi.g...@gmail.com> wrote:
> 2011年7月6日11:43 Katsunori FUJIWARA <flying.fo...@gmail.com>:
> > win32mbcs.py 中の funcs 文字列に列挙されている対象関数に
> > mercurial.util.checkwinfilename を追加すれば回避できると思うのですが、
> > この認識であってますかね？ ＞ Goto さん
>
> 実際にはエイリアスである util.checkosfilename の方をラップしないとダメですね。
> そういうわけで藤原さんのパッチではなく、以下のパッチを使用してみてください。>all
>
> -------------------(cut here)-----------------------
> diff -r 4b58d9402c43 hgext/win32mbcs.py
> --- a/hgext/win32mbcs.py Thu Dec 09 13:40:28 2010 +0900
> +++ b/hgext/win32mbcs.py Wed Jul 06 12:32:01 2011 +0900
> @@ -129,7 +129,8 @@
> funcs = '''os.path.join os.path.split os.path.splitext
> os.path.splitunc os.path.normpath os.path.normcase os.makedirs
> mercurial.util.endswithsep mercurial.util.splitpath mercurial.util.checkcase
> - mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath'''
> + mercurial.util.fspath mercurial.util.pconvert mercurial.util.normpath
> + mercurial.util.checkosfilename'''
>
> # codec and alias names of sjis and big5 to be faked.
> problematic_encodings = '''big5 big5-tw csbig5 big5hkscs big5-hkscs
> -------------------(cut here)-----------------------
起きないでしょうか?
_("filename contains '%s'...") % c が非 ascii str と unicode の連結になりそう。
※ 投稿に失敗したので Web から再送します
Toru Uetani
> Mercurial 1.9 でファイル名の互換性チェックが入ったみたいで、それに引っかかって
> いるようです。
そんな変更が入ったんですか・・・
> とりあえず以下のコードをエクステンションとしてでっち上げておけば、当座はしのげる
> と思います。
西原さんにいただいたコードを保存して、以下のように指定しましたが、動作に影響はありませんでした・・・
[extensions]
nocheckwinfilename = D:\Work\nocheckwinfilename.py
> 大して実害はありませんが、修正版が近いうちに出る予定なので、2.1.1 を待ったほうが
> よさそうです。
慌てて2.1に移行する理由もないので、とりあえず2.0.5に戻したほうがよさそうですねえ。
Yuya Nishihara
On Jul 6, 10:14 pm, Toru Uetani <toru.uet...@gmail.com> wrote:
> > とりあえず以下のコードをエクステンションとしてでっち上げておけば、当座はしのげる
> > と思います。
>
> 西原さんにいただいたコードを保存して、以下のように指定しましたが、動作に影響はありませんでした・・・
-- nocheckwinfilename.py --
from mercurial import util
def extsetup():
util.checkwinfilename = lambda path: None
----
Goto さんが指摘されているとおり、 checkosfilename もラップしないといけないようです。
util.checkosfilename = lambda path: None を追加したら動くかも。
> 慌てて2.1に移行する理由もないので、とりあえず2.0.5に戻したほうがよさそうですねえ。
そう思います。
TortoiseHg 2.1 には重要なバグが 2 件上がっています。もうすぐ 2.1.1 が出ると思いますので、
しばしお待ちください。
- push/pull 画面で例外ダイアログを吐くことがある (修正済み)
https://bitbucket.org/tortoisehg/thg/issue/853
- thgw.exe から GUI マージツールを起動できない (修正中)
https://bitbucket.org/tortoisehg/thg/issue/891
何か昨日から Google アカウントが変。
Toru Uetani
> Goto さんが指摘されているとおり、 checkosfilename もラップしないといけないようです。
> util.checkosfilename = lambda path: None を追加したら動くかも。
以下のようなコードに変更したら動きました。
from mercurial import util
def extsetup():
util.checkwinfilename = lambda path: None
util.checkosfilename = lambda path: None
> TortoiseHg 2.1 には重要なバグが 2 件上がっています。もうすぐ 2.1.1 が出ると思いますので、
> しばしお待ちください。
2.1.1が出るまでおとなしく待つことにしました。
> - push/pull 画面で例外ダイアログを吐くことがある (修正済み)
> https://bitbucket.org/tortoisehg/thg/issue/853
おっと。そういえばsubrepo使ってるリポジトリで、こんなエラーを見たような気がします。
Shun-ichi Goto
> checkwinfilename() のメッセージが日本語化されると、 UnicodeDecodeError が
> 起きないでしょうか?
> _("filename contains '%s'...") % c が非 ascii str と unicode の連結になりそう。
「日本語化されると」というところが、原文(英文)の場合とどう違うのか、
いまいちいわんとするところが理解できてないのですが、
c は _winreservedchars のうちの1文字のunicodeなので、asciiに変換可能ですので
例えば "invalid char '%s'" % u'?' はエラーになりませんし、
"invalid char '%s'" が unicodeでu"不正な文字 '%s'" になろうが、utf-8で
"不正な文字 '%s'" になろうがエラーにはならないと思います。
c が ASCIIにエンコードできない文字だった場合にはUnicodeDecodeErrorが生じますが、
cもbaseもチェックに引っかかってメッセージを作成する時、その値はASCII範囲の文字(列)
(_winreservednames および _winreservedchars の要素のどれかと等値)
なので結局エラーは生じないかと。
--
Shun-ichi GOTO
Yuya Nishihara
> 2011年7月6日21:42 Yuya Nishihara <y...@tcha.org>:
> > checkwinfilename() のメッセージが日本語化されると、 UnicodeDecodeError が
> > 起きないでしょうか?
> > _("filename contains '%s'...") % c が非 ascii str と unicode の連結になりそう。
>
> 「日本語化されると」というところが、原文(英文)の場合とどう違うのか、
> いまいちいわんとするところが理解できてないのですが、
> c は _winreservedchars のうちの1文字のunicodeなので、asciiに変換可能ですので
> 例えば "invalid char '%s'" % u'?' はエラーになりませんし、
> "invalid char '%s'" が unicodeでu"不正な文字 '%s'" になろうが、utf-8で
> "不正な文字 '%s'" になろうがエラーにはならないと思います。
化しようとして UnicodeDecodeError が起きるのではないか? ということです。
原文は ascii なので unicode("invalid char '%s'") されても問題ありませんが、
Mercurial の _() はローカルエンコード文字列を返すはずなので、8 ビット文字と
unicode がバッティングするのではないかと思います。
Shun-ichi Goto
> u"不正な文字 '%s'".encode(local_encoding) % u'?' で、左オペランドを unicode
> 化しようとして UnicodeDecodeError が起きるのではないか? ということです。
> 原文は ascii なので unicode("invalid char '%s'") されても問題ありませんが、
> Mercurial の _() はローカルエンコード文字列を返すはずなので、8 ビット文字と
> unicode がバッティングするのではないかと思います。
そか、decode エラーですね。
byte文字列 % unicode文字列
の際に byte文字列をunicode化するという挙動だってことを理解してませんでした。
具体的には以下のコードで最後のやつだけは UnicodeDecodeErrorが生じるということですね。
----
msg = u"invalid char: '%s'"
print msg % '?' # OK
print msg.encode('cp932') % '?' # OK
print msg % u'?' # OK
print msg.encode('cp932') % u'?' # OK
msg = u"不正な文字: '%s'"
print msg % '?' # OK
print msg.encode('cp932') % '?' # OK
print msg % u'?' # OK
print msg.encode('cp932') % u'?' # NG!
---
うーむ。どうしてくれませう。
checkwin32filename() の中身をごっそり書き換えるくらいしか思いつかないです。
同様のことはラップしてる他の関数にもありそうですが未チェック。
--
Shun-ichi GOTO
Katsunori FUJIWARA
2011年7月7日1:32 Shun-ichi Goto <shunic...@gmail.com>:
"hg add" でのディレクトリ指定で "adding ..." 表示されるのを思い出して、
ソースを確認してみたのですが、表示を行っている mercurial.cmdutil.add() は:
- repo.walk() が返すファイル名は local encoding
- _("msg") が返すフォーマット文字列は local encoding
なので、正常に機能する、という理解であってます？ ＞ 西原さん
で、add 機能の確認の際に、mercurial.scmutil.casecollisionauditor() で
まずそうな実装を見つけました。
メッセージ翻訳の際に、文字大小で衝突の可能性を検出する機能が追加されたのは
認識していたのですが、実装を見てみると、ファイル名文字列に対して問答無用で
lower() メソッドを起動していました。
ここで lower() 起動対象となる文字列は、repo.walk() が返す文字列なので、
local encoding だと考えると、ascii ベースな lower() の適用の場合、例えば
2バイト目に ascii の「A」に相当する 0x41 を持つ「ア」(0x83 0x41)は、
"a"(0x61) 化の巻き添えを喰らって、「ヂ」(0x83 0x61)と衝突する濡れ衣を
着せられてしまう気がするのですが、私の認識はあってますでしょうか？
これだと、バックスラッシュを含む「駄目文字」を持つ符号化方式以外にも、
煽りを食う符号化方式が出てきそうな雰囲気が ....
case-collision は設定で無効化もできますが、そうすると本当に衝突する
ケースに対して適切に警告できなくなってしまいますから、痛し痒しですねぇ。
win32mbcs の対象符号化以外にも checkwinfilename や
casecollisionauditor で誤判断される符号化方式ってありそうですから、
判定関数をラップするよりは、生文字列を直接弄っている実装を修正した方が
よさそうな気がします。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Yuya Nishihara
妙案は思い浮かばないです。 Goto さんの指摘に対して、 Matt さんが localstr
みたいな対処方法を検討しよう、と返されていますが、むむ。
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/43056/focus=43065
_() が、 str % unicode で (str.decode(enc) % unicode).encode(enc) する
ようなラッパークラスを返すぐらいしか思いつけない。
> "hg add" でのディレクトリ指定で "adding ..." 表示されるのを思い出して、
> ソースを確認してみたのですが、表示を行っている mercurial.cmdutil.add() は:
>
> - repo.walk() が返すファイル名は local encoding
> - _("msg") が返すフォーマット文字列は local encoding
>
> なので、正常に機能する、という理解であってます？ ＞ 西原さん
そうです。問題が起きるのは local encoding str を unicode へ変換する時です。
str と unicode を連結しようとすると、 str は自動で unicode へ変換されます。
そこで仮に str に非 ascii 文字が含まれていると、エンコーディングが分からないので
変換に失敗し、 UnicodeDecodeError になります。
> で、add 機能の確認の際に、mercurial.scmutil.casecollisionauditor() で
> まずそうな実装を見つけました。
>
> メッセージ翻訳の際に、文字大小で衝突の可能性を検出する機能が追加されたのは
> 認識していたのですが、実装を見てみると、ファイル名文字列に対して問答無用で
> lower() メソッドを起動していました。
>
> ここで lower() 起動対象となる文字列は、repo.walk() が返す文字列なので、
> local encoding だと考えると、ascii ベースな lower() の適用の場合、例えば
> 2バイト目に ascii の「A」に相当する 0x41 を持つ「ア」(0x83 0x41)は、
> "a"(0x61) 化の巻き添えを喰らって、「ヂ」(0x83 0x61)と衝突する濡れ衣を
> 着せられてしまう気がするのですが、私の認識はあってますでしょうか？
>
> これだと、バックスラッシュを含む「駄目文字」を持つ符号化方式以外にも、
> 煽りを食う符号化方式が出てきそうな雰囲気が ....
少し話がそれますが、ラテン系のウムラウトがついたような文字ってどうなるんですかね?
ファイルシステムの解釈と Python の str.lower() の解釈が一致しないことも
あるような気がします。
Shun-ichi Goto
>> > うーむ。どうしてくれませう。
>> > checkwin32filename() の中身をごっそり書き換えるくらいしか思いつかないです。
>> > 同様のことはラップしてる他の関数にもありそうですが未チェック。
>
> 妙案は思い浮かばないです。 Goto さんの指摘に対して、 Matt さんが localstr
> みたいな対処方法を検討しよう、と返されていますが、むむ。
>
> http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/43056/focus=43065
>
> _() が、 str % unicode で (str.decode(enc) % unicode).encode(enc) する
> ようなラッパークラスを返すぐらいしか思いつけない。
自分も第一印象はそんな感じでしたが、Mattの意図するところはファイル名文字列の
ためのクラスをstrから継承して作って、いまのようにunicodeにして渡すのではなく
そのオブジェクトを渡すというものを考えてるのではないかぁと想像してます。
基本はstrなオブジェクトなんだけど、split()やイテレーションなどのmbcsに対する
危険な操作をそのクラス内で吸収できるようにしてcheckfilename()内ではstrとして
あつかえれば % の際の問題も生じない。てな具合に。
--
Shun-ichi GOTO
Yuya Nishihara
ああ、なるほど。それなら Mercurial らしい実装になりますね。
実装が進んで、 mercurial.util で定義されたファイル名系関数がファイル名オブジェクトを
意識するようになると、 win32mbcs の機能がコアに統合されるかもしれない。
ファイル名ラッパーを使って、 fixutf8 も何とかしようと考えられているのかもしれない
ですね。