バージョン管理システムについて語るスレ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/ 75 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:00:45 ] >>69 > そもそもコミットしてないデバッグ目的の変更や、 > addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って > そこに残しているの。 Subversionの欠点をそのまま踏襲しているのか？ 76 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:20:06 ] >>69 >**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。 77 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:23:16 ] なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう 78 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 10:30:24 ] Twitterでやれ 79 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:01:41 ] >>77 bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、 誰も理解できないことを書いているのだから、批判と捉えても仕方がない 80 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 11:04:12 ] 話がかみ合ってなくないか 81 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:03:18 ] >56 > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） svnでrepo/projectname/trunkをチェックアウトするのではなく、 repo/projectnameをチェックアウトしてたって事？ 変わった使い方だな。 82 名前：methane mailto:sage [2011/01/27(木) 12:19:23 ] >>81 project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo をそれぞれ並列にチェックアウトして作業したい事ってない？ 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 というかこれもう完全にbzrの話じゃないよね。 hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 83 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:24:13 ] >82 > hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。 いや、あんたがsvn, bzrの特徴として言い出したんだが。 84 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:41:23 ] >>82 > project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo > をそれぞれ並列にチェックアウトして作業したい事ってない？ > 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。 hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、 gitもhgもcheckoutで切り替えればいいだけ わざわざ全部チェックアウトするメリットは？ 85 名前：methane mailto:sage [2011/01/27(木) 12:41:47 ] >>83 単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って 思われても仕方ないな。すまん。 86 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:50:52 ] >>81 > svnでrepo/projectname/trunkをチェックアウトするのではなく、 > repo/projectnameをチェックアウトしてたって事？ > 変わった使い方だな。 なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか 87 名前：methane mailto:sage [2011/01/27(木) 12:53:10 ] >>84 だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で 持っておきたい場合があるんだって。 コミットしない変更とか、バージョン管理下に無いテストデータとか、 色々なゴミファイルが作業ツリー配下にできるから。 別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に 合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。 というかこれもう完全にバージョン管理ツールの話じゃなくて個人の 作業スタイルの話だからやめようぜ。 88 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:54:05 ] Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。 89 名前：methane mailto:sage [2011/01/27(木) 12:55:07 ] >>86 bzr switch そのものズバリのコマンドがある。 90 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 12:59:49 ] >>87 > だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で > 持っておきたい場合があるんだって。 > コミットしない変更とか、バージョン管理下に無いテストデータとか、 > 色々なゴミファイルが作業ツリー配下にできるから。 分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が 発生すること自体が理解できないのだが MercurialのMQや"git merge --squash"のような機能が無いってことなのか？ 91 名前：methane mailto:sage [2011/01/27(木) 13:22:14 ] >>90 違う違う、 cd 1.1; ./foo --test > test.result; cd .. cd 1.2; ./foo --test > test.result; cd .. diff -u 1.1/test.result 1.2/test.result とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 コードとか、ローカルで動かすための設定ファイルetcetc... 最初から最後まで一切バージョン管理には含めないゴミだけど 作業中は残しておきたいファイルだよ。 もちろんそういったデータを管理するためのプラグインもある(pipeline) んだけど管理するよりディレクトリ分けた方が楽だと思ってるから 分けてるだけ。 だからもうこの話もうやめようぜ。 俺は作業ツリーを複数持ちたいからそうしているだけなのに、 なんでいちいちbzrの機能不足という事に繋げようとするのかねぇ。 bzrが使いにくくないと何か困ることがあるんだろうか？ 92 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:26:28 ] > bzrが使いにくくないと何か困ることがあるんだろうか？ Bazaarが使いづらいと、指摘している人が多いだけ。 このスレだと、比較分析されて当然。 93 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:36:04 ] >>91 > >>90 > 違う違う、 > > cd 1.1; ./foo --test > test.result; cd .. > cd 1.2; ./foo --test > test.result; cd .. > diff -u 1.1/test.result 1.2/test.result > > とか、あとは勝手に入れてコミットには絶対含めないprintfデバッグ用 > コードとか、ローカルで動かすための設定ファイルetcetc... > 最初から最後まで一切バージョン管理には含めないゴミだけど > 作業中は残しておきたいファイルだよ。 これこそMercurialのMQの目的なのだが。 gitにも輸出されているそうだし。 94 名前：methane mailto:sage [2011/01/27(木) 13:49:43 ] >>93 うん、だから、 > もちろんそういったデータを管理するためのプラグインもある(pipeline) > んだけど管理するよりディレクトリ分けた方が楽だと思ってるから > 分けてるだけ。 って言ってる。 作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨 しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている わけでもない。 ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを 分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した だけで、別にこれがbzrのスタイルではない。 bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では どのスタイルも推奨していない。 が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる 可能性が高い。 95 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 13:51:58 ] 自由度の高さがわかりづらさを助長してる部分はあるよね、Bazaar。 といいつつ愛用しているけれど。 96 名前：デフォルトの名無しさん [2011/01/27(木) 15:24:29 ] bzr init --append-revisions-only したリポジトリに対して pull をすると、以下のようにでる。 No revisions to pull. しかし、push しようとすると、以下のようになる。 bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/var/tmp/bazaar/trunc/". これ、もしかしてuncommitして編集しなおさないとpush不可能？ 不便すぎない？ Bazaarの--append-revisions-onlyを使っている人いるの？ 97 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:51:15 ] Bazaarは色物だな。 98 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 15:53:11 ] >>56 > （作業中のブランチを数か月放置して復帰するときにやりかけの > 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を > 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか） これって、Trac/Redmineを使えば良いだけでは？ 99 名前：デフォルトの名無しさん mailto:sage [2011/01/27(木) 16:39:14 ] >>94 > bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では > どのスタイルも推奨していない。 > が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、 > bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる > 可能性が高い。 Bazaarの言う自由度の高さとGitのこれとは何が違うの？ Pro Git 5.1 Git での分散作業 分散作業の流れ progit.org/book/ja/ch5-1.html 100 名前：methane mailto:sage [2011/01/27(木) 16:45:30 ] >>96 branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。 例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる ことがあるけど、それを防止するのが append-revisions-only だから。 append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。 bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes bzr-colo 使わない場合は、bzr checkout example.com/repo/trunk; cd trunk; して、 bzr merge ../my_own_branch; bzr commit; のように、「trunkがローカルブランチを取り込む」 ようにしないといけない。 大規模プロジェクトでは、この trunk に merge して commit は、限られたコミッタが 手動でやるか、PQMみたいなシステムが自動的にレビューが完了したブランチを取り込む。 TortoiseBZR の開発では、細かい修正は直接 trunk の checkout 上でやってしまっている。 bzr-colo を使って作業ツリー1つでローカルブランチ使いたい場合は、多分こんな感じになる。 bzr colo-ify --trunk-name=local # (初回のみ)colo化して、今のブランチを local という名前にする bzr branch example.com/repo/trunk colo:upstream --bind # (初回のみ)trunkを upstream という名前で持ってくる bzr switch colo:upstream bzr merge colo:local bzr commit -m "Add XXX feature." 2回目以降は、bzr switch, bzr merge, bzr commit で良くなる。 ただし、coloは常用してないので嘘ついてるかも。後でやってみる。 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に変換するとしたら使いものにならない

---

---

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

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