23:46:07Bazaarでござ~る。00:41:31.87bzrの開発者にはPythonのコミッタもいるからね。いいとこ取りになると思うよ。09:28:01.15>>225gitの良い所はhgがすでに取り込んでいる。gitのブランチに相当するものはhgではbookmarkというものだが、1.7までは本体にバンドルされている拡張だったのが、1.8ではコア機能になった。hgの名前付きブランチに相当するものはgitには無い。gitのブランチは利点もあるが欠点もある。利点はローカルブランチを気軽に作れて消せること。欠点はリモートブランチを意図的にせよ事故にせよ消せること。codeがgitでなくhgを選んだ理由。codeがgitでなくhgを選んだ理由。スタイルよりも好きだっていってるけど、僕も同意する。(コミットがリモートに対して行われる)を使ってブランチを管理している。好きだっていってるけど、僕も同意する。どこに書いてある?目に見えて流量の減っているbzrのMLが活況ついていると思ったら、hgの主要コミッタとhgを使っているXEmacsの人が投稿しているのか。immutable.だから、これはhgの名前付きブランチのコストが高いという問題があって、gitのブランチ相当のhgのbookmarkが1.8からコアに含まれたということを、bzrの人々が知っていないってこと。CPythonの2.7、3.2という名前付きブランチは、svnからの移行ということで、もっと具体的に言うと、hgsubversionで変換したから、そうなっているってこと。CPythonは、2.xと3.xを同時にメンテナンスしなければならないという特殊なアプリ。CPythonの名前付きブランチの方針はここに書かれている。言ってたのはその部分じゃなくて、その1つ上の段落。commitってしたら、直接リモートにコミットされる。なり、最終的に履歴は1回のマージのコミットだけで済む。>>240具体的に教えて。20:16:36.69>>241gitのremote/masterとローカルのmasterには基本的には関連は無い。masterは失敗する。master:hogehogeとやればpushはできる。これはhgの場合、リモートに無名ブランチ=ヘッドが新しくできる状態。hgの無名ブランチとgitのブランチは同等。bzrの人のgitとhgの理解が足りない。違いについて勝手に補足しただけで、もとのMLの人もその違いはちゃんと認識していると思うよ。mirror"が勘違い。forwardが可能な場合、勝手にマージされるからそう勘違いされる。hgはpullしても勝手にはマージされない。00:01:49.17>>245別に勘違いしてるわけじゃないと思うけどな。しないといけないことくらい基礎だし。model."のあとがこの人の勝手な解釈で、hgの主要コミッタからhgの名前付きブランチについての指導が入っている。この人はこの時点で何も分かっていない。それを引き合いにして「同意する」なんて書いているのは無知の上乗せ。hgの主要コミッタからhgの名前付きブランチについての指導が入っている。この人はこの時点で何も分かっていない。モデルを参考にしてみたら?」ていう程度の話。それを引き合いにして「同意する」なんて書いているのは無知の上乗せ。対して無知なのは認めるよ。精通しているわけじゃないかもね。23:42:20.91MLでコマンドラインのi18nが話題になってたから、TortoiseBZRやMercurialの仕組みを流用して基本部分だけ作ってみた。22:10:23.96>>426ファイル名がロケールに依存するという間違った設計のため、まともな実装が出来ないのであった。22:24:07.05>>443ヘルプテキストやメッセージを翻訳するのとファイル名がどう関係するの?僕が試しに作ったi18n機能は、LANG=ja_JP.eucJPな人には翻訳メッセージはファイル名と同じくEUC-JPで表示するし、これで問題ないと思うんだが。22:29:43.75>>445methaneさんよ。22:38:11.66>>445~/.bzr.logも複数の文字コードが混在する可能性があります。00:16:26.67>>446スルーばかりしてたら本当の問題報告を見逃してしまうかもしれないので、、、>>447それって全然i18nの実装と関係ない話だよね?もちろん、ロケールが登録されてないサーバーで使えるようになるのはいい事だけど、ロケール登録されてないって結構レアケースだし、困っている人どれくらいいるんだろ?ウチの会社はbzrインストールしているサーバーではロケールを登録した。>>448ファイルシステムエンコーディングと出力エンコーディングは別。標準出力に出力されるファイル名はUTF-8になる。そもそもそこら辺はオフトピックで、i18nの実装に絡む部分じゃない。ロケールが登録されてないサーバーマシンのロケール(/etc/sysconfig/i18n)とログインシェル(~/.profile)は別。ファイルシステムエンコーディングと出力エンコーディングは別。標準出力に出力されるファイル名はUTF-8になる。01:21:52.72>>452>全角半角は関係ないのでしょうか?はい、関係ありません。マシンのロケール(/etc/sysconfig/i18n)とログインシェル(~/.profile)は別。自体がスッカラカンで、LANGに何を設定してもutf-8のロケールにできない状況だから、マシンのロケールとログインシェル以前の問題。オプションができたら良いねというのがMLで言ってた話題。65001が効かないってあったけど?どの話題のことだろう?今まで話してたのは基本的にUnix系の話題の話で、Windowsでは言語設定にかかわらずファイルパスは全部W系APIを使ってUnicodeで扱うから、チェックアウト時と違う言語設定にしてもファイルパスには全く影響ない。はい、関係ありません。Mercurialをパクるなら全て正しくパクりましょう。言語設定にしてもファイルパスには全く影響ない。Mercurialをパクるなら全て正しくパクりましょう。ファイルシステムエンコーディングと出力エンコーディングは別。標準出力に出力されるファイル名はUTF-8になる。65001が効かないってあったけど?これに繋がるのは、出力エンコーディングをUTF-8にする=chcp65001、という認識だったんですね。出力エンコーディングはUTF-8になっていません。自体はWindowsで出力エンコーディングをUTF-8にする有効な手段を提供していないので、このオプションなり環境変数が導入されるといいですね。Mercurialをパクるなら全て正しくパクりましょう。10:48:03.78>>457i18nと折り返し機能は別物。折り返ししてるからここで対策必要だったわ。扱うつもりだから対策も楽だな。扱うつもりだから対策も楽だな。11:11:53.63>>461いや、それくらいちゃんと解ってるから。バイト文字列が渡された時もわざわざUnicodeにデコードしてから処理してエンコードしているけど、bzrの場合はバイト文字列が来た場合はそもそもコマンド名などのUS-ASCII文字だって仮定できるので、入力がUnicodeのときだけ対応すれば良いから楽だってこと。家のWindows7(64bit)だとうまくいきません。12:10:50.78なんのこっちゃ。́・ω・`)Subversionで管理されていたソースコードを持ってきて(チェックアウトではなく)、そのソースコードをBazaarで管理して修正を始めました。今回の101~をつなげられるなら、そうしてもいいのですが。Bazaarで無理なら、gitでもMercurialでも構いません。