バージョン管理システムについて語るスレ8

1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ] バージョン管理システムについて語りましょう ●過去スレ バージョン管理システムについて語るスレ pc11.2ch.net/test/read.cgi/tech/1193332500/ バージョン管理システムについて語るスレ2 pc11.2ch.net/test/read.cgi/tech/1215520728/ バージョン管理システムについて語るスレ3 pc12.2ch.net/test/read.cgi/tech/1228366972/ バージョン管理システムについて語るスレ4 pc12.2ch.net/test/read.cgi/tech/1242918130/ バージョン管理システムについて語るスレ5 pc12.2ch.net/test/read.cgi/tech/1255241922/ バージョン管理システムについて語るスレ6 hibari.2ch.net/test/read.cgi/tech/1270640436/ バージョン管理システムについて語るスレ7 hibari.2ch.net/test/read.cgi/tech/1283780922/ 331 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:10:29.20 ] >>329 日本語のファイルの取り扱いが問題ありません 他はすべて日本語の扱いに問題有り 332 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:28:01.24 ] >>331 つ>>8 svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。 333 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:28:50.00 ] >>332 それは既にパッチあるだろ 334 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:30:51.91 ] パッチどころか本家で既に対応済み 何年前の話だよ… 335 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:51:51.89 ] で、bzrも2.3だといけるらしい。 336 名前：デフォルトの名無しさん mailto:sage [2011/04/25(月) 23:53:23.91 ] gitとhgｵﾜﾀｗ 337 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 00:20:04.65 ] svnは対応はできていません。 subversion.tigris.org/issues/show_bug.cgi?id=2464 bzrもだめです。 https://bugs.launchpad.net/bzr/+bug/172383 338 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 00:26:22.54 ] OSXなんて捨て捨て 339 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 00:28:10.54 ] windowsとlinuxとの連携ならsvnとbzrが最強なんだっけか？ 340 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 01:10:25.90 ] ユニコードに過度な期待は禁物です 341 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 08:48:59.32 ] http://iup.2ch-library.com/i/i0291902-1303775239.jpg 342 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:05:53.42 ] >>337 Mac ports の svn は対応パッチ済みです。 bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている ケースは解決されています。 Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の 扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、 Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に 対するコストパフォーマンスの高い対応策。 343 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:15:25.50 ] >>342 GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD 344 名前：341 mailto:sage [2011/04/26(火) 09:21:33.19 ] 言い忘れたけど上の画像はOSXね 345 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:22:06.40 ] >>343 このスレでだれがそんなFUDを言ってる？ それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD？ 346 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:22:54.02 ] >>342 > Mac OS X が出るまではみんなSubversionの（スピードはともかく）ファイル名の > 扱いには満足していたんだし、 満足なんかしてないよ。 波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに ファイル名変換が行われるものなんか使わないよ。 347 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:23:56.85 ] >>344 Windowsでばーかというファイルを作成してMacでチェックアウトして 編集せずに git diff したら、何もしてないのにファイル名が変更されたって 報告されない？ 348 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:26:52.41 ] >>345 つ>>208 349 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:27:11.56 ] >>347 GitHubにでもレポ作ってくれれば試すよ 興味あるし 350 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:30:01.93 ] >>346 たしかに、みんなは言い過ぎだな。 でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば 一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて CVSからSubversionへの変化を喜んでいた。 WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々 設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に 戻りたいという人がどれくらいいるか。 351 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:30:43.31 ] >>347 gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー 352 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:34:07.00 ] >>349 https://gist.github.com/941544/ git clone git://gist.github.com/941544.git 353 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:35:06.00 ] >>351 Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ？ 354 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:36:39.26 ] >>353 cygwin、fixutf8 355 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:37:13.47 ] >>351 あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、 コマンドラインからファイル名指定するときに普通に日本語入力システムで 変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。 356 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:39:58.20 ] >>354 fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫？ cygwinを使う方法については、cygwinが必要だというのを明示せずに 「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、 ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。 357 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:40:24.04 ] >>355 hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。 hg add/remove/addremoveは自動認識するし。 358 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:43:16.46 ] >>357 チェックアウトしたファイルを開こうとして $ vim ばーか.txt ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。 359 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:47:23.72 ] まとめ 日本語を使うのなら、、 集中型ならsvn 分散型ならbzr 日本語は使わないのなら、、 速いのが好きならgit googleが好きならhg 360 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:49:21.95 ] >>358 たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・ 361 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 09:49:36.10 ] >>352 git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか 勉強にはなったが、どうしようかなあ 362 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 10:40:10.09 ] ソースコードの中身ならまだしも、ファイル名に日本語とか情弱の極みだろ 363 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 11:18:24.43 ] まだ>>362みたいなことを言ってる馬鹿がいるんだな 364 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 11:23:43.49 ] ぶっちゃけどのバージョン管理システムかの問題じゃなくてWindowsの問題だよね 365 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 11:29:07.24 ] ファイル名はutf-8ではなくutf-7にしよう 366 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 13:08:35.45 ] 自分、英語がプアなもんでファイル名に日本語が欠かせません！ 英語にしてもそこそこ把握できる場合（予想） 『ワルプルギスの淫夢.txt』 『奴隷少佐ルクレツィア.txt』 英語にしたら把握に時間がかかるか訳がわからない場合（予想） 『目覚めると従姉妹を護る美少女剣士になっていた.txt』 『俺のフラグはよりどりみデレ.txt』 というような場合もあるんじゃないかな？ 仮定、想像の話だけど。 367 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 13:36:52.35 ] 確かにそうだな。 それはそれとして、そのtxtの中身について話をしたいのだが。 368 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 13:45:20.85 ] 非実在テキストファイルですから。 何分、仮定、想像の話なので。 369 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 14:22:22.90 ] >>364 Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。 どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず ファイルをアップロードするときとか、zipファイルの中身とかいろんな 場面に影響するので凶悪。 370 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 14:49:34.62 ] >>369 ファイル名の話してんのに何言ってんの？ 論点のすり替え乙 371 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:19:32.78 ] >>370 ファイル名の話だよ？ Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。 Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。 372 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:23:47.02 ] 厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを のぞいたらWinXP (01年) だから、10年以上ではないな。 373 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:24:17.13 ] いやだからファイル名の 話だろ？ 374 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:24:26.87 ] Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。 375 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:25:13.49 ] あ 最新レス見ずに書いちゃった 376 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:27:30.17 ] >>374 Python はどちらでも扱えるようにしている。 open(u"ほげ") ならUnicode APIで、open("ほげ") ならASCII APIを使う。 bzrは前者、mercurialは後者を使ってる。 cygwin は、 fopen("ほげ"); すると、 "ほげ" を utf-8 でデコードして、 UTF-16にエンコードして、 CreateFileW に渡している。 377 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:31:31.57 ] >376 それがクソって言ってんの 378 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:34:02.13 ] >>377 えー、これがクソならどうしろと、、、 C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で すごく使いにくくなるんだけど。 Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと 思ってる。 379 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 17:11:59.63 ] というかそれならMercurialで問題になってるのは何なの 380 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:26:12.29 ] >>379 mercurial.selenic.com/wiki/EncodingStrategy 381 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:29:23.48 ] >>379 英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。 UTF-16としては不正な値も格納される。 382 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:33:09.11 ] NTFSがUTF-16とは書いていないか。 > kernel has a mix of byte-width and wide character APIs 383 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 10:45:25.11 ] Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。 Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき やすいのは日本語対応が進んでいるBazaarでしょうか？ 384 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:04:37.41 ] その条件ならシェル統合がまともに動くMercurialじゃないか 385 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:10:24.25 ] Bazaarは日本語対応進んでいないでしょ。 386 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:15:43.07 ] Windows onlyならhg、bzrのどちらでもいいと思う でかいファイルを扱うならhgかな 387 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:16:05.67 ] 書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、 Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。 388 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:18:50.31 ] bitbucketとlaunchpadなら断然bitbucket githubの方がもっといいけど 389 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:19:07.53 ] 分散だと日本語環境はbzrが独占状態なのよねぇ。 他は何をやってんのやら。 390 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:23:24.89 ] >>389 > 分散だと日本語環境はbzrが独占状態なのよねぇ。 > 他は何をやってんのやら。 「Windowsのファイルシステムの」日本語環境でしょ。 Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。 391 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:27:13.00 ] そうはいっても ○○支社向け.docとか ○○部長月間予定.xlsとか いう日本語ファイル名って結構使うからねぇ 392 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:31:50.17 ] >>391 リポジトリを分ければ良い。 そういうファイルがあるところだけsvnにすれば良い。 svnはリポジトリを一ヶ所にするというのが一般的のようだが、 別に一ヶ所にする必要もない。 393 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:35:09.66 ] 運用ポリシーで複数の管理システムを使うのはちょっとね 後々の事を考えてシンプルにしないとさ 394 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:46:48.22 ] Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ？ 395 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:48:38.19 ] >>394 CP932に無いUnicodeの文字も増えてきているからねえ・・・ 396 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 14:21:26.83 ] ○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。 どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。 そういうのはsvnでいいんじゃね。 397 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 14:50:19.02 ] >>396 Mercurialはロックを実装する気でいるぞ。 mercurial.selenic.com/wiki/LockExtension/NewDesign 398 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 15:39:09.50 ] >>397 分散型でlockとかｗｗｗ というのは釣りですが、それでワークフローがうまく回るなら良いですね。 特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、 バグトラッカとかでやりとりするよりもスムーズかも知れない。 399 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 15:39:15.31 ] かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。 結局のところ、運用でごまかせって感じになっているのがなぁ。 誰だよ1バイト圏意外に住んでいるやつは。 400 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:10:18.30 ] >>396 中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ 人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん 401 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:13:02.54 ] ×無駄なんて ○不都合だなんて 失敬 402 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:41:36.52 ] >>400 ワードとかエクセルのマージ作業はどうするの？ 403 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:43:59.18 ] それって別に分散かどうかは関係ないよね 404 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:49:45.42 ] >>403 マスターリポジトリにプッシュするまでもない物をとりあえず確認するために 個人のローカルリポジトリにアクセスしたりとか 個別相談受けて訂正する時にその人のローカル除いたりとか色々ある メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ 405 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 14:39:55.41 ] gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ でもバイト列で扱う方針なら変換できないよね localeに応じて変換するのだろうか マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？ 406 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:02:14.19 ] 根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。 やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。 それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。 gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。 (bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える) 407 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:18:23.72 ] ・欧米人にはファイル名にUnicodeを使う需要が無い ・欧米人はファイル名にCP1252(ISO-8859-1)が使えれば満足 ・欧米人はLinuxでもファイル名はISO-8859-1を使っている ・Linux/UnixでロケールをUTF-8にしているのは日本人が主 ・日本人はLinuxでEUC-JP/Shift_JIS/UTF-8の混在に慣れているが、これは日本の特殊事情 408 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:23:53.14 ] >>406 > hgは単に開発者が無理解なだけだろ。 無理解とは思えないが。 mercurial.selenic.com/wiki/EncodingStrategy cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。 bzrがcmd.exeでCP932の方が無理解だと思うが。 409 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:29:36.71 ] hgが叩かれる時のリンクじゃないかそれ cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな 410 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:33:04.46 ] >>409 cmd.exeでwは使えない。 wprintf()がcp932とかcp1252の時にデータが欠損する。 411 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:35:38.99 ] >>409 bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。 412 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:37:30.80 ] 使えるっての。 libcではなく自分でAPI呼べよ 413 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:45:46.84 ] >>412 chcp 1252 して日本語混じりのをwprintfしたら何が出力される？ だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては 正しいと思うが。 414 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:09:39.19 ] >>413 cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない 恐れがあるからという理由があったはず。 まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変 だからだろうけど。 CLIでunicode使いたかったら cygwin + minitty が最強。 415 名前：414 mailto:sage [2011/05/01(日) 16:10:15.09 ] >>412 だった。 416 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:14:13.63 ] UnicodeじゃないからUnicode版API使えないと言いつつ、 得体の知れないバイト列をANSI版APIに流し込む矛盾。 417 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:15:14.84 ] >>412 出力って何のこと？diffとか？ 418 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:18:07.25 ] >>416 CP932と繁体字がASCIIと互換が無いから問題なのであって、 それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。 419 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:18:31.36 ] >>413 さすがPowerShell ISEさんに隙はなかった・・・ 420 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:21:34.79 ] >>419 Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、 PowerShellでも問題ない。これが正しい多言語化。 421 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:23:30.72 ] --encodingだった。 --encodingmodeってのもある。 422 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:40:05.99 ] >>420 や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね chcpコマンドがまともに機能するWin7標準のアプリ 従来の対話型コマンドが動作しないのが玉に瑕 423 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:00:58.60 ] >>422 PowerShell ISEってフルで言わないとだめなのか。 PowerShell ISEでMercurialでchcp 65001が最強。 424 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:09:01.55 ] >>423 うん、同意 425 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:26:56.00 ] chcp 65001 をしたら、fopenがutf-8を受け付けるようになるの？ 426 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:10:01.43 ] >>313 そのwprintfはwcstombsしてるんだろ。 まずWriteConsoleWでUTF-16のまま無変換出力を試みる →エラーになったらコンソール以外にリダイレクトされてるから 保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile がWindowsでの正しいUnicode対応コンソールアプリの作り方。 427 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:10:24.54 ] >>413だった 428 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:29:52.71 ] >>426 Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。 mercurial.selenic.com/wiki/EncodingStrategy#Functions にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。 429 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:35:44.01 ] >>428 すまん、アンカーミスなんだ。 元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。 430 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:50:32.48 ] >>429 バージョン管理と何の関係があるの？ 431 名前：デフォルトの名無しさん mailto:sage [2011/05/04(水) 12:27:28.61 ] PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利 シェルとして使いにくいのが悲しい点

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef