- 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/
- 101 名前：methane mailto:sage [2011/01/27(木) 16:49:44 ]
- >>99
svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。
会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。
今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。
- 102 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 16:53:42 ]
- >>101
それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね
- 103 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 17:04:14 ]
- >>102
それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。
- 104 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 17:15:15 ]
- >>103
Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの？
- 105 名前：103 mailto:sage [2011/01/27(木) 18:17:04 ]
- 知らんよ。
動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。
でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?
- 106 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 18:51:20 ]
- じゃあ、プロジェクト管理は何でやっているの？
もしかしてExcel？
だから日本語ファイル名が必要なの？
append-revisions-onlyを使わないとリビジョン番号が変わるんだよね？
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの？
make distでリビジョン番号を埋め込んだりするよね？
これもリビジョン番号変わっちゃうよね？
- 107 名前：methane mailto:sage [2011/01/27(木) 19:02:33 ]
- なんか会社での運用の話になってるな。
あまり普通の会社じゃないからどれだけ役に立つか判らないけど、
TortoiseSVNに慣れたユーザーは以外とTortoiseBZR使って文句が無い
Eclipse, Netbeans は使ってる人いるけど、バージョン管理はコマンドライン
bzr-svn で svn プロトコルで serve することができるので、それを使って
trunk から svn としてチェックアウト＆コミットがどれくらい実用に耐えるのかは
今後検討しようと思ってる。
Trac, hudson は問題なし。Redmineは使ってない。
チケットはtracのURLを設定ファイルに書いておけば、 commit --fixes で連携可能だけど、
僕が見てる範囲だとあまりチケットとコミットの連携はしてないでユルく運用してる。
make dist をするプロジェクトは少ないんだけど、 >>101 に書いた通り
基本 checkout でやりたい人だけ branch する運用なので、 append-revision-only
で問題なく運用できてる。
- 108 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 19:10:28 ]
- bzr send使えばいいし
- 109 名前：96 mailto:sage [2011/01/27(木) 19:38:11 ]
- オレの問題は解決しないの？
- 110 名前：デフォルトの名無しさん [2011/01/27(木) 19:41:58 ]
- >>109
これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない
- 111 名前：methane mailto:sage [2011/01/27(木) 19:45:00 ]
- >>109
append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100
- 112 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 20:05:11 ]
- bzrもLaunchpadもばりばり使ってるけどね
- 113 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:04:08 ]
- >>28
> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
mercurial.selenic.com/wiki/Win32LongFileNamesExtension
- 114 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:14:29 ]
- >>32
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65
- 115 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 11:35:20 ]
- >>28
> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
mercurial.selenic.com/wiki/fncacheRepoFormat#Hashing_of_long_paths
> Paths inside the store that would be longer than 120 chars are now hash encoded.
- 116 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 12:41:08 ]
- >>111
リビジョン番号が変化するか、不便を強いられるかの2択か。
- 117 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 12:46:12 ]
- どんなんかなー
- 118 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 14:06:25 ]
- それは、ChangeLogを書き換えてコミットしたら、もうリポジトリはChangeLogとは
違うバージョンになってるってことと比べて、どの程度の不便さなん？
- 119 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 14:11:57 ]
- ChangeLogはCVSのバッドノウハウじゃない？
リリースノートは別管理でしょ？
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが
- 120 名前：デフォルトの名無しさん mailto:sage [2011/01/28(金) 18:32:49 ]
- >>118
ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
svnlogbrowser.org/demo/
- 121 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 10:55:21 ]
- >>297
これって何で美乳なの？微乳じゃいかんの？
- 122 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 11:18:08 ]
- なるほど。乳をバージョン管理か。そいつは思いつかなかったｗ。
- 123 名前：デフォルトの名無しさん [2011/01/29(土) 11:48:47 ]
- >>121
美乳 EUCでぐぐってみよう
- 124 名前：デフォルトの名無しさん mailto:sage [2011/01/29(土) 11:55:48 ]
- >>121 は落ちたスレへの誤爆と思われ
次スレがあるのでそちらへどうぞ
hibari.2ch.net/test/read.cgi/tech/1291075205/
297 名前：デフォルトの名無しさん [sage]： 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
- 125 名前：デフォルトの名無しさん mailto:sage [2011/02/12(土) 12:37:38 ]
- gitのイメージカラーってマリオ＆ルイージだよね
- 126 名前：デフォルトの名無しさん mailto:sage [2011/02/13(日) 18:46:29 ]
- >>23
直っていない
https://bugs.launchpad.net/bzr/+bug/172383/comments/15
- 127 名前：methane mailto:sage [2011/02/13(日) 22:51:01 ]
- >>126
irclogs.ubuntu.com/2011/01/25/%23bzr.html#t07:44
- 128 名前：デフォルトの名無しさん mailto:sage [2011/02/15(火) 02:29:43 ]
- 【bzr】Bazaarでバージョン管理 Rev 3
hibari.2ch.net/test/read.cgi/tech/1297704483/
- 129 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 16:58:30 ]
- Hg/Git/Bzr のシェアってどんなもんなんですかね？
- 130 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:08:32 ]
- Git 6/Hg 3/Bzr 1
- 131 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:18:08 ]
- Git優勢なんすね
- 132 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:20:26 ]
- >>130
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
- 133 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:35:28 ]
- qa.debian.org/popcon-graph.php?packages=bzr,git-core,mercurial,subversion&show_installed=on&want_legend=on&from_date=2008-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
- 134 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 17:49:06 ]
- >>133
一面ではあると思うが参考になったthx。
- 135 名前：デフォルトの名無しさん mailto:sage [2011/02/16(水) 22:40:17 ]
- 大事なのは、
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
- 136 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 13:50:37.67 ]
- 最近、
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
- 137 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 14:50:33.54 ]
- >>136
文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
- 138 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:47:16.08 ]
- >>137
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が？前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
- 139 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:54:28.95 ]
- Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも
対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
- 140 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 15:56:36.88 ]
- そりゃ"Double Byte"が3バイト以上だったりしたら困るわな
- 141 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:04:56.51 ]
- 2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・
- 142 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:17:51.15 ]
- >>141
DBCS=MBCSだからCP932用
UTF-16とは関係ない
- 143 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 16:36:34.15 ]
- UTF-16でサロゲートペア対応だから2byteじゃねーし。
- 144 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 17:29:00.69 ]
- >>142
あー、ごめん、Unicode策定してた連中に言ったつもりだった。
- 145 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 18:04:01.31 ]
- ん？
- 146 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 19:37:32.05 ]
- Windows対応アプリを作る場合は、APIコールの度に毎回UTF-8→UTF-16変換してW版APIを呼ぶのが正道なんだけど
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
- 147 名前：デフォルトの名無しさん mailto:sage [2011/02/23(水) 23:20:04.23 ]
- >>141
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
- 148 名前：147 mailto:sage [2011/02/23(水) 23:21:23.77 ]
- UTF-16というか、UTF-8以外のUnicode表現。UTF-16決め打ちじゃなくて
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
- 149 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:28:17.70 ]
- 文字としては、さすがにUCS-4で足りるだろうから
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
- 150 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:34:29.78 ]
- >>149
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
- 151 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:36:42.45 ]
- >>150
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
- 152 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:42:06.92 ]
- Javaって今は内部UTF-16でインターフェースは好きにできる感じじゃなかったっけ。
WindowsはUTF-16固定？
- 153 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:46:12.23 ]
- 普通は内部文字コードは UCS4 じゃないの
UTF-16 は負の遺産という認識だったけど
- 154 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:15.38 ]
- UTF-16はサロゲートペアが気持ち悪いのでちょっと・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
- 155 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:40.00 ]
- つうか、後顧の憂いを残さない為には、内外共にUTF-8にしておくのがベストなんじゃ？
- 156 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:49:54.49 ]
- >>153
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
- 157 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:04.46 ]
- >>155
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
- 158 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:24.00 ]
- >>155
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
- 159 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:52:55.00 ]
- 内部コードを何にするかが、バージョン管理システムにどう影響するんだ？
いい加減スレ違いだからUnicodeスレに行け。
- 160 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:53:13.04 ]
- ってか、こんな問題の関わりたくないからファイル名はバイナリだ、とかいう割り切りになってんだろうね。
- 161 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:54:28.69 ]
- >>160
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
- 162 名前：デフォルトの名無しさん mailto:sage [2011/02/24(木) 23:57:10.63 ]
- >>156
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
- 163 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:13:29.48 ]
- プログラム用のバージョン管理システムが扱う文字の範囲なんて殆ど ascii の範疇なんだから、
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
- 164 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:16:13.76 ]
- 保存用はそりゃUTF-8だろ。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
- 165 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:26:42.61 ]
- 元々はWindowsでファイル名が化ける云々…というのが発端で、
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
- 166 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 00:33:43.11 ]
- >>165
Windows に限定した話題なら、Unicode APIを使え、でFAだろ。
内部コーディングにUTF-8を使おうがUTF-32を使おうが、Unicode APIを
呼ぶときにUTF-16に変換すれば良い。
Javaが内部ではUTF-16でファイル名を扱ってても、Linuxでファイル名を
指定するときはUTF-8にエンコードしてシステムコール呼ぶのと一緒。
- 167 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 07:25:35.98 ]
- >>166
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
- 168 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 07:56:03.02 ]
- >>167
内部エンコーディングの意味わかってる？
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
- 169 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:05:16.70 ]
- >>168
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね？
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね？
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね？
- 170 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:11:27.04 ]
- >>169
そこがパフォーマンス上ボトルネックになるとでも思っているのか…
- 171 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:18:17.40 ]
- >>170
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ？
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの？
- 172 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:33:17.66 ]
- >>171
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
- 173 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:39:29.22 ]
- >>172
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
３２ビットOSでは動かなくなるよ？
- 174 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:45:24.40 ]
- >>173
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの？
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん？
- 175 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 08:50:59.41 ]
- >>174
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
- 176 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 09:03:22.14 ]
- >>175
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
- 177 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 09:39:03.80 ]
- >>176
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
- 178 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:03:21.47 ]
- >>177
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
- 179 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:23:05.55 ]
- >>178
うん、bzrの設計はおかしい。
2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
- 180 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:35:36.51 ]
- >>179
> 2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
> Linuxのutf-8ロケールも実用的になっていた。
意味不明。UTF-16 は Unicode のほとんどの文字集合を表現可能で、
UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
さらに言うと、bzrはPythonの unicode 型を使っているだけで、Pythonは
UTF-16とUTF-32を切り替え可能。bzrはPythonの内部エンコーディングに
依存してないし、リポジトリフォーマットではUTF-8を使ってる。
Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
> Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
> 知らなかったとしか思えない。
bzr 開発してるのは Ubuntu Linux の開発してる Canonical で、
少なくともお前よりは Linux の多言語対応について判ってると思うぞ。
- 181 名前：180 mailto:sage [2011/02/25(金) 10:37:41.52 ]
- >UTF-16 は Unicode のほとんどの文字集合を表現可能で、
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の（まだ文字が割り当てられていないコードを含む）ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
- 182 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:38:27.52 ]
- >>180
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
- 183 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:38:56.90 ]
- bzrはどの分散管理よりもマルチ環境で使える
これが全て
他のは日本語環境だと使い物にならない
- 184 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:40:51.98 ]
- そっか。じゃあ俺は Git を使うわ。問題が起きた事無いし。
- 185 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 10:41:55.69 ]
- 例えばSubversionの場合、
WindowsではUTF-16に変換してUnicode APIを呼ぶ（リポジトリ内部はUTF-8？）
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな？
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない？
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
- 186 名前：180 mailto:sage [2011/02/25(金) 10:49:26.64 ]
- >>185
subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
- 187 名前：180 mailto:sage [2011/02/25(金) 10:50:37.47 ]
- >>182
Unicodeに統一したいの？したくないの？
まったく意味が判らないよ。
- 188 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 11:34:29.81 ]
- ファイル名なんかよりもコミットログ、特にコミットユーザ名が一番重要。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
- 189 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 11:50:50.34 ]
- >>186
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では？
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな？
- 190 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 12:20:48.99 ]
- >>188
全部大事
全部満たしてるのがbzrだけ
- 191 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 12:27:11.43 ]
- >>190
日本人の人名で普通に使われている文字がbzrでは使えないよね？
- 192 名前：methane mailto:sage [2011/02/25(金) 12:40:06.97 ]
- >>191
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
- 193 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 13:25:59.99 ]
- でも・・・正解が欲しいよ・・・ママン・・・
- 194 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 13:43:27.41 ]
- そんなものを求めたら宗教戦争に巻き込まれるだけだと思うぞ
- 195 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 14:51:51.55 ]
- いあ、add時のプラットフォームとエンコーディングをメタ情報に持った上でファイル名自体はバイナリとして保存、
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
- 196 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 14:54:01.19 ]
- >>195
よう、いいだしっぺ
- 197 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:17:44.23 ]
- もうMIMEエンコードして保持しとけよ
- 198 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:17:45.41 ]
- >>195
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの？
- 199 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 15:21:00.63 ]
- >>198
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか？
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
- 200 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:29:57.73 ]
- >>197
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
- 201 名前：デフォルトの名無しさん mailto:sage [2011/02/25(金) 16:33:31.64 ]
- >>199
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
|
 |
