11/01/20 12:26:04
バージョン管理システムについて語りましょう
●過去スレ
バージョン管理システムについて語るスレ
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ2
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ3
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ4
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ5
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ6
ｽﾚﾘﾝｸ(tech板)
バージョン管理システムについて語るスレ7
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
11/01/20 12:26:45
●関連スレ
CVS 1.3 [UNIX板]
ｽﾚﾘﾝｸ(unix板)
CVS導入スレ～ Rev.3 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
subversion バージョン管理【サブバージョン】 [Linux板]
ｽﾚﾘﾝｸ(linux板)
Subversion r12 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
Git 2 [プログラム板]
ｽﾚﾘﾝｸ(tech板)
【分散型バージョン管理】 Mercurial 【hg】
ｽﾚﾘﾝｸ(tech板)
【bzr】Bazaarでバージョン管理 Rev 2
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
11/01/20 12:27:35
●関連サイト
CVS
URLﾘﾝｸ(ximbiot.com)
Subversion
URLﾘﾝｸ(subversion.tigris.org)
Git
URLﾘﾝｸ(git-scm.com)
Bazaar
URLﾘﾝｸ(bazaar.canonical.com)
Mercurial
URLﾘﾝｸ(mercurial.selenic.com)
Darcs
URLﾘﾝｸ(www.darcs.net)
GNU arch
URLﾘﾝｸ(www.gnu.org)
monotone
URLﾘﾝｸ(www.monotone.ca)
Visual SourceSafe
URLﾘﾝｸ(www.microsoft.com)
●チュートリアル
Subversionによるバージョン管理(日本語訳)
URLﾘﾝｸ(subversion.bluegate.org) (アクセスできない場合は↓)
URLﾘﾝｸ(www.caldron.jp)
Git入門
URLﾘﾝｸ(www8.atwiki.jp)
git チュートリアル (バージョン 1.5.1 以降用)
URLﾘﾝｸ(www8.atwiki.jp)
Bazaar Documentation Overview
URLﾘﾝｸ(wiki.bazaar.canonical.com)
Mercurial の使い方のチュートリアル
URLﾘﾝｸ(mercurial.selenic.com)
4:デフォルトの名無しさん
11/01/20 12:28:25
立てました。
5:デフォルトの名無しさん
11/01/20 12:30:20
バージョン管理システムの選び方
1. 同時に一人しか編集できないロック機構が必要ですか？
│
├(YES)→ Subversionをおすすめします。ただし、オンラインでしか開発できなくなります。
(NO)
↓
2. 日本語のファイル名が存在し、リポジトリをMS-Windows（CP932）とLinuxやMacintosh OS X（UTF-8）で同期を取りますか？
│
├(YES)→ Subversionを選択してください。WindowsとLinuxでなら、Bazzarで日本語ファイル名の同期も可能かも知れません。
(NO)
↓
3. 実験的なソースコードを頻繁に作成しますか？
│
├(NO)→ Bazzarをおすすめします。Bazzarは他のDVCSに比べると分岐が手間ですが、それ以外は遜色ありません。
(YES)
↓
4. MS-Windowsでの利用をしますか？
│
├(YES)→ Mercurialをおすすめします。設定で、日本語コミット文やCP932のファイル名も取り扱えます。
(NO)
↓
6:デフォルトの名無しさん
11/01/20 12:31:24
5. GUIやEclipseでの利用を重視しますか？
│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか？
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
（チェンジセット: 4:ae4c01d241ab）
7:デフォルトの名無しさん
11/01/20 12:32:11
811 名前：デフォルトの名無しさん [sage]： 2011/01/01(土) 17:45:53
皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。
Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。
Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。
Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。
8:デフォルトの名無しさん
11/01/20 12:35:22
589 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:31:11
お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください
【bzr】Bazaarでバージョン管理 Rev 2
ｽﾚﾘﾝｸ(tech板:491-495番)
491 ：デフォルトの名無しさん：2010/12/10(金) 18:02:33
bzr初心者です。2.2.2をMac上で使おうとしてますが、扱うファイル名に濁点が含まれていると
うまく動いてくれません。NFCとNFDの問題が絡んでいるということはわかったのですが、
何か回避方法はあるんでしょうか？（何かパッチを当てるとか。）
492 ：デフォルトの名無しさん：2010/12/10(金) 22:45:46
# だれかutf-8-macなcodec作ってくれ
493 ：デフォルトの名無しさん：2010/12/11(土) 08:29:26
なんだBazaarでも日本語使えないのか
494 ：デフォルトの名無しさん：2010/12/11(土) 14:48:30
Subversionでも解決しているに>>1の「多言語に完全対応」というのは嘘だったのですね
495 ：デフォルトの名無しさん：2010/12/11(土) 21:48:19
svnが遭遇してきた問題点とその解決策が
ハッカーの間で共有知になってないことが問題なのかもしれぬ
591 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:41:23
>>589-590
こっちでいいじゃん
URLﾘﾝｸ(d.hatena.ne.jp)
592 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:42:16
ここも
URLﾘﾝｸ(www23.atwiki.jp)
593 名前：デフォルトの名無しさん [sage]： 2010/12/12(日) 01:44:57
あとここ
ｽﾚﾘﾝｸ(tech板:466-474番)
9:デフォルトの名無しさん
11/01/20 15:00:23
MacHgがなかなか良い。
10:デフォルトの名無しさん
11/01/20 15:14:59
749 名前：デフォルトの名無しさん [sage]： 2010/12/30(木) 19:23:52
append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。
URLﾘﾝｸ(twitter.com)
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。
11:デフォルトの名無しさん
11/01/20 15:15:43
751 名前：デフォルトの名無しさん [sage]： 2010/12/30(木) 19:46:58
もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、
履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。
通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた
細かいリビジョンを無視して、それをメインラインにマージしたコミット１つにまとめて表示できる。
なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な１つのコミットにするみたいな
作業が要らない。
(もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い)
なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは
メインラインはローカルブランチに、中央ブランチはサブラインになって、それを push すると
中央ブランチのメインラインが置き換わってしまう。
中央 1:A - 2:B - 3:C - 4:D
ローカル 1:A - 2:B - 3:X - 4:Y -(中央からマージ)- 5:Z
(この状況でローカルから中央に push)
中央 1:A - 2:B - 3:X - 4:Y - 5:Z (中央のサブライン 2:B - 2.1.1:C - 2.1.2:D - 5:Z)
(リビジョン番号3と4に割り当てられているリビジョンが変わってる)
これを許さないのが append_revisions_only
12:デフォルトの名無しさん
11/01/20 18:04:24
そろそろ、zipを超えるバージョン管理システムがでるかな？
13:デフォルトの名無しさん
11/01/20 18:44:34
それならzipよりもmkdirっていうバージョン管理システムの方がずっと強い
14:デフォルトの名無しさん
11/01/20 22:46:02
しばらく見てなかったけどJGitが、結構使えるようになってるな。
JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも
日本語ファイル名も含めて今のところ相互運用に問題は無い。
まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in
に頼らないといけないところが難点。EGit の UI は悪くないけどね。
15:デフォルトの名無しさん
11/01/20 22:59:57
20110120最新-2.zip みたいな悪夢見さすな。
16:デフォルトの名無しさん
11/01/21 00:10:52
インストールすると自動的にhomeに公開、ダウンロード、音楽、ビデオ、デスクトップ、
文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ
バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな
がいします。
17:デフォルトの名無しさん
11/01/21 00:43:44
他人と共同作業じゃなくて、自分用のバックアップ目的で使うには、Bazaarが最強との結論に達した。
18:デフォルトの名無しさん
11/01/21 00:55:06
俺は個人で使うのはgit、他人と共同作業で使わせるのはbzrという結論になった
本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど
19:デフォルトの名無しさん
11/01/21 01:41:43
前スレでTeam Foundation Server使用したことある人がいたようなので
使用感はどんな感じか聞いてみたい。
特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。
Perforceの対抗馬になるようなら嬉しいんだけど
20:前スレ989
11/01/21 23:57:50
>>19
それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。
まだホワイトペーパー（URLﾘﾝｸ(download.microsoft.com)）
しかまだ見てないです。ちなみにシェルブ機能の紹介はP.57にあるね。
（ここから下は全部憶測）
個人的には、そもそもIIS+ASP.NET+SharePoint+MSSQLが要るという時点で、パフォーマンスはあまり期待してなかったり。
少なくとも、DBサーバーをインストールするマシンは十分なI/O性能を確保しないと悲惨なことになると思う。
その辺は伝統的な3層クラサバとまんま同じノウハウが適用できる（というか必要になる）ハズ。
あとは評価してみないことには分からないけど、ウチの場合、100MB近いMDBを数十個扱う予定なので、
その結果分かったことがあれば、ここに書くよ（忘れてなければ……）。
21:デフォルトの名無しさん
11/01/22 04:43:43
sshの公開鍵をくださいと言ったら、秘密鍵と公開鍵の両方がメールで送られてきた。
BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。
22:デフォルトの名無しさん
11/01/24 17:36:10
TracやRedmineを併用している？
23:methane
11/01/25 16:58:26
>>8
URLﾘﾝｸ(svn.apache.org)
ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。
24:デフォルトの名無しさん
11/01/26 06:51:31
>>23
これで「社会が憎い.properties」が使えるわけですね。
25:デフォルトの名無しさん
11/01/26 10:39:24
>>23-24
誰得アプリに磨きがかかったのですね
26:デフォルトの名無しさん
11/01/26 11:49:05
>>25
リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。
・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・ﾃﾞｻﾞｲﾅ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。
27:デフォルトの名無しさん
11/01/26 11:51:09
全員クビにしろよ
28:methane
11/01/26 12:28:18
>>26
リポジトリの構造ってMercurial優位だっけ？
bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
29:デフォルトの名無しさん
11/01/26 12:36:33
>>28
表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。
・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。
GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。
30:methane
11/01/26 12:44:09
>>29
あぁ、 .bzr とか .hg 内部のファイル／データ構造という意味じゃないのね＞リポジトリの構造
そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
31:デフォルトの名無しさん
11/01/26 12:51:50
>>28
> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い
bzrはコピーをサポートしている？
FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない？
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか？
> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
cygwin
あと、例の拡張
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
進化している
マイナーチェンジで基本は全く変わっていないけど
32:methane
11/01/26 13:02:40
>>31
bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。
FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。
>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう？
33:デフォルトの名無しさん
11/01/26 13:12:22
>>32
> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。
2GB制限は？
> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう？
当然知っているでしょ？
MAX_PATHのことを言っているんでしょ？
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張
34:methane
11/01/26 13:31:30
>>33
bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、
pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は
気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。
MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の
コードポイント数が制限を受ける。
この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを
スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると
カレントディレクトリとか一切使えなくなる。
例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は
utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。
35:デフォルトの名無しさん
11/01/26 13:40:40
hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
って、これも知っているよね？
もう１つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。
36:デフォルトの名無しさん
11/01/26 13:48:26
>>30
>そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
リビジョン番号30（ハッシュタグ0b70750bdf9b02597741301c695ff46bc75036d4）から分岐するとする。
Mercurial (3ステップ):
hg update -C -r 30
[編集]
hg commit -m "以前のバージョンから分岐"
Git (4ステップ):
git branch NewBranch 0b70750b
git checkout NewBranch
[編集]
git commit -m "以前のバージョンから分岐"
Bazaar (4ステップ):
cd ..
bzr branch -r revno:30 ./OldBranch ./NewBranch
cd NewBranch
[編集]
bzr commit -m "以前のバージョンから分岐"
Bazaarはブランチがファイルシステムと連動しているSVN風なので、ブランチの切り替えが手間。マージもファイルパスを指定する必要がある。
Gitはブランチ切り替えは容易だが、ブランチの切り替えが必要。
Mercurialは、編集対象のチェンジセットと連動して、自動的に無名ブランチが切られる。
個人的には、Bazaarが洗練されているようには思えない。
37:デフォルトの名無しさん
11/01/26 13:59:05
>>36の続きだが、Bazaarの「リポジトリ」もあまり良いコンセプトに思えない。
準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。
「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。
後から「リポジトリ」を使うこともできるが、移行作業はいる。
38:デフォルトの名無しさん
11/01/26 14:07:06
>>36
Git (3ステップ):
git checkout -b NewBranch 0b70750b
[編集]
git commit -m "以前のバージョンから分岐"
39:デフォルトの名無しさん
11/01/26 14:09:15
>>36
git checkout -b NewBranch 0b70750b
40:methane
11/01/26 14:12:49
>>35
>hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
>って、これも知っているよね？
bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
という制限もない。
>もう１つの拡張の方も横取りしている。
>パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
>そこがANSI APIになっている。
もう一つって、win32なんちゃらの事かな？
最近hg使ってないから最近の事情に疎くて、、、またhg使い始める予定だから調べとこ。
一応言っておくけど、 hg のリポジトリフォーマットが効率悪くて使い物にならないとか
言ってもなければ思ってもないよ。
>>26 を hg のリポジトリフォーマットがbzrより優秀と誤読したから反論しただけ。
リポジトリフォーマットは hg, git, bzr 全部、ソースコード管理目的では十分な効率をしている。
hgでMAX_PATHが問題になるのもレアケースで、僕が使ってる限り問題になったことはない。
41:methane
11/01/26 14:13:42
>>36-37
つbzr-colo
42:デフォルトの名無しさん
11/01/26 14:53:47
>>41
何それ？
43:デフォルトの名無しさん
11/01/26 15:19:30
>>40
> >>35
> >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
> >って、これも知っているよね？
>
> bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
> 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
> という制限もない。
URLﾘﾝｸ(foozy.bitbucket.org)
何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する
が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、
ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。
別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、
日々の利用における “体感” に非常に影響を及ぼします。
訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを
低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。
44:methane
11/01/26 18:32:36
>>42
簡単に言えば、gitみたいな名前付きブランチを実現するもの。
bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。
>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる（現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える）
45:デフォルトの名無しさん
11/01/26 19:00:02
>>44
> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。
＼ ∩─ｰ､ ====
＼／ ● ､_ ｀ヽ ======
/ ＼( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ―
､ (＿／ ノ /⌒l
/＼＿＿＿ノﾞ＿/ / =====
〈 ＿_ノ ====
＼ ＼＿ ＼
＼＿__） ＼ ====== (´⌒
＼ ＿＿_ ＼＿＿ (´⌒;;(´⌒;;
＼＿＿＿）＿＿＿）(´;;⌒ (´⌒;; ズザザザ
46:デフォルトの名無しさん
11/01/26 23:34:10
誤解を恐れずに言えば、Gitにはブランチは存在しない
旧来のブランチの機能を果す何物かがあるだけ
47:デフォルトの名無しさん
11/01/26 23:54:13
mercurialの設計で一番の間違いはブランチを名前で管理できると思ったところだと思う。
48:methane
11/01/27 00:12:55
え、じゃぁ
URLﾘﾝｸ(progit.org)
ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの？
まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo
49:デフォルトの名無しさん
11/01/27 00:40:14
突然だけど、Meld と Diffuse ってどっちが使いやすい？
プラットホームは Linux で。ほかにも何かおすすめがあれば。
50:デフォルトの名無しさん
11/01/27 00:43:20
>>48
bzrはよく分かんないんだけど、
gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、
内部的には「ブランチを作る」という機能は無いと言っていい。
ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので
「ブランチを作る」というコマンドは存在する（エイリアスを作るだけのコマンド）
51:methane
11/01/27 00:47:49
>>50
うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、
>>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて
いいよね。
52:デフォルトの名無しさん
11/01/27 00:54:56
>>50
馬鹿なの？
ブランチの意味知らないんなら喋らないほうがいいよｗｗｗ
53:デフォルトの名無しさん
11/01/27 01:10:01
極端な例だけど下記のような分岐をした場合、各VCSはどのようにbranchを管理するでしょうか？
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿branch1
＿×＿×＿×＿×＿×＿×＿×＿branch2
×＿×＿×＿×＿×＿×＿×＿＿branch3
＿×＿×＿×＿×＿×＿×＿×＿branch4
×＿×＿×＿×＿×＿×＿×＿＿branch5
54:デフォルトの名無しさん
11/01/27 02:27:26
>>52
は？
55:デフォルトの名無しさん
11/01/27 04:46:40
MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。
「ブランチ」に対するアプローチが、
・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用
と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。
56:methane
11/01/27 07:43:19
>>55
だから俺は >>30 で
>どちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
って言ったんだけどね。
俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
だから、自分では bzr-colo はあまり使ってない。
ブランチ管理についてできるだけ特定のスタイルを押し付けないのがbzrの方針。
逆に言えば「こういうフローで作業しましょうね」という指針を提供してくれていないので
初心者にはどう使ったら良いのか判らなくなるし、gitと同じワークフローを採用すると
gitよりもブランチ管理が手間になったりもする。
この点は結構前からBazaarのMLで議論されていて、bzr-colo は git と同じワークフローを
楽にするプラグインという以上に、将来の bzr の "bzr init" で作成するのを
standalone branchじゃなくてcolocated branchにするための proof of conceptにも
なっている。
57:デフォルトの名無しさん
11/01/27 07:44:04
>>47
Mercurialの「名前付きブランチ」は「おまけ」
リポジトリの分離と名無しブランチでも運用可能
cvsのブランチのように消さないことを前提としている
名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た
「名前付きブランチ」と「リビジョン番号」はgitには無い
58:デフォルトの名無しさん
11/01/27 07:46:13
>>48
> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo
用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか
59:デフォルトの名無しさん
11/01/27 07:54:07
>>56
> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。（作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い
60:methane
11/01/27 07:58:51
>>58
いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。
で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、
この「コミットに対する名前による参照」って git はなんて定義しているの？
「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、
hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから
hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。
61:デフォルトの名無しさん
11/01/27 08:04:16
>>60
ローカルブランチ、リモートブランチを勉強してから出直してきな
62:methane
11/01/27 08:07:51
>>59
> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。
> github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
意味が分からない。
リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？
63:デフォルトの名無しさん
11/01/27 08:09:19
>>60
> 僕が git が定義している用語を知らないし興味もないってだけだよ。
bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか
64:methane
11/01/27 08:12:07
>>61
gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。
どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。
65:methane
11/01/27 08:13:34
>>63
本当にそうなら bzr-colo なんて存在しないよ。
66:デフォルトの名無しさん
11/01/27 09:01:24
>>62
> **俺は** 目に付くところ（ディレクトリ）にあった方が、「あの作業中のブランチどこおいてたっけ？」ってならない
Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ？」と考える必要がある。
目につくところに無いのは、Bazaarとしか思えない。
67:デフォルトの名無しさん
11/01/27 09:05:55
>>62
> > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
> 意味が分からない。
> リポジトリのフォークって個人所有のブランチ切る以上の意味があるの？
意味が分からない
「個人所有のブランチ」って何？
68:デフォルトの名無しさん
11/01/27 09:19:32
>>62
> だからこういう個人の主観による優劣で議論する気ないんだってば。
「個人の主観」ではなく、VCS運用の基本ではないか。
Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。
Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。
69:methane
11/01/27 09:35:19
>>66
だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。
**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ？」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。
>>67
自分がpushできるブランチ
>>68
個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
ワークフローか？個人が便利に使えたらそれで良いじゃん。
70:デフォルトの名無しさん
11/01/27 09:40:39
>>69
> >>68
> 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
> ワークフローか？個人が便利に使えたらそれで良いじゃん。
bzrは個人でしか使えないという認識で良いのですね？
71:デフォルトの名無しさん
11/01/27 09:41:55
なんか煽るだけしかできない奴が張り付いてるな
72:デフォルトの名無しさん
11/01/27 09:42:12
お前らってホント色んなネタで宗教戦争できるのな
73:methane
11/01/27 09:44:07
>>70
そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、
最初からローカル作業の話なんだけど？
開発サイトでのブランチの管理と、ローカルでの作業ツリー＋ブランチの管理は別物。
74:デフォルトの名無しさん
11/01/27 09:49:59
methaneたんﾍﾟﾛﾍﾟﾛ
75:デフォルトの名無しさん
11/01/27 10:00:45
>>69
> そもそもコミットしてないデバッグ目的の変更や、
> addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
> そこに残しているの。
Subversionの欠点をそのまま踏襲しているのか？
76:デフォルトの名無しさん
11/01/27 10:20:06
>>69
>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。
77:デフォルトの名無しさん
11/01/27 10:23:16
なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう
78:デフォルトの名無しさん
11/01/27 10:30:24
Twitterでやれ
79:デフォルトの名無しさん
11/01/27 11:01:41
>>77
bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、
誰も理解できないことを書いているのだから、批判と捉えても仕方がない
80:デフォルトの名無しさん
11/01/27 11:04:12
話がかみ合ってなくないか
81:デフォルトの名無しさん
11/01/27 12:03:18
>56
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事？
変わった使い方だな。
82:methane
11/01/27 12:19:23
>>81
project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない？
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
83:デフォルトの名無しさん
11/01/27 12:24:13
>82
> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
いや、あんたがsvn, bzrの特徴として言い出したんだが。
84:デフォルトの名無しさん
11/01/27 12:41:23
>>82
> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない？
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは？
85:methane
11/01/27 12:41:47
>>83
単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという
ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って
思われても仕方ないな。すまん。
86:デフォルトの名無しさん
11/01/27 12:50:52
>>81
> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事？
> 変わった使い方だな。
なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか
87:methane
11/01/27 12:53:10
>>84
だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。
別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。
というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。
88:デフォルトの名無しさん
11/01/27 12:54:05
Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。
89:methane
11/01/27 12:55:07
>>86
bzr switch そのものズバリのコマンドがある。
90:デフォルトの名無しさん
11/01/27 12:59:49
>>87
> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。
分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか？
91:methane
11/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:デフォルトの名無しさん
11/01/27 13:26:28
> bzrが使いにくくないと何か困ることがあるんだろうか？
Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。
93:デフォルトの名無しさん
11/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
11/01/27 13:49:43
>>93
うん、だから、
> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。
って言ってる。
作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。
ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。
bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。
95:デフォルトの名無しさん
11/01/27 13:51:58
自由度の高さがわかりづらさを助長してる部分はあるよね、Bazaar。
といいつつ愛用しているけれど。
96:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/01/27 15:51:15
Bazaarは色物だな。
98:デフォルトの名無しさん
11/01/27 15:53:11
>>56
> （作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか）
これって、Trac/Redmineを使えば良いだけでは？
99:デフォルトの名無しさん
11/01/27 16:39:14
>>94
> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。
Bazaarの言う自由度の高さとGitのこれとは何が違うの？
Pro Git 5.1 Git での分散作業 分散作業の流れ
URLﾘﾝｸ(progit.org)
100:methane
11/01/27 16:45:30
>>96
branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。
例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる
ことがあるけど、それを防止するのが append-revisions-only だから。
append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。
URLﾘﾝｸ(bazaar.launchpad.net)
bzr-colo 使わない場合は、bzr checkout URLﾘﾝｸ(example.com) 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 URLﾘﾝｸ(example.com) 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
11/01/27 16:49:44
>>99
svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。
会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。
今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。
102:デフォルトの名無しさん
11/01/27 16:53:42
>>101
それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね
103:デフォルトの名無しさん
11/01/27 17:04:14
>>102
それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。
104:デフォルトの名無しさん
11/01/27 17:15:15
>>103
Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの？
105:103
11/01/27 18:17:04
知らんよ。
動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。
でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?
106:デフォルトの名無しさん
11/01/27 18:51:20
じゃあ、プロジェクト管理は何でやっているの？
もしかしてExcel？
だから日本語ファイル名が必要なの？
append-revisions-onlyを使わないとリビジョン番号が変わるんだよね？
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの？
make distでリビジョン番号を埋め込んだりするよね？
これもリビジョン番号変わっちゃうよね？
107:methane
11/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:デフォルトの名無しさん
11/01/27 19:10:28
bzr send使えばいいし
109:96
11/01/27 19:38:11
オレの問題は解決しないの？
110:デフォルトの名無しさん
11/01/27 19:41:58
>>109
これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない
111:methane
11/01/27 19:45:00
>>109
append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100
112:デフォルトの名無しさん
11/01/27 20:05:11
bzrもLaunchpadもばりばり使ってるけどね
113:デフォルトの名無しさん
11/01/28 11:04:08
>>28
> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
URLﾘﾝｸ(mercurial.selenic.com)
114:デフォルトの名無しさん
11/01/28 11:14:29
>>32
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
URLﾘﾝｸ(bitbucket.org)
115:デフォルトの名無しさん
11/01/28 11:35:20
>>28
> >>26
> リポジトリの構造ってMercurial優位だっけ？
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
URLﾘﾝｸ(mercurial.selenic.com)
> Paths inside the store that would be longer than 120 chars are now hash encoded.
116:デフォルトの名無しさん
11/01/28 12:41:08
>>111
リビジョン番号が変化するか、不便を強いられるかの2択か。
117:デフォルトの名無しさん
11/01/28 12:46:12
どんなんかなー
118:デフォルトの名無しさん
11/01/28 14:06:25
それは、ChangeLogを書き換えてコミットしたら、もうリポジトリはChangeLogとは
違うバージョンになってるってことと比べて、どの程度の不便さなん？
119:デフォルトの名無しさん
11/01/28 14:11:57
ChangeLogはCVSのバッドノウハウじゃない？
リリースノートは別管理でしょ？
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが
120:デフォルトの名無しさん
11/01/28 18:32:49
>>118
ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
URLﾘﾝｸ(svnlogbrowser.org)
121:デフォルトの名無しさん
11/01/29 10:55:21
>>297
これって何で美乳なの？微乳じゃいかんの？
122:デフォルトの名無しさん
11/01/29 11:18:08
なるほど。乳をバージョン管理か。そいつは思いつかなかったｗ。
123:デフォルトの名無しさん
11/01/29 11:48:47
>>121
美乳 EUCでぐぐってみよう
124:デフォルトの名無しさん
11/01/29 11:55:48
>>121 は落ちたスレへの誤爆と思われ
次スレがあるのでそちらへどうぞ
ｽﾚﾘﾝｸ(tech板)
297 名前：デフォルトの名無しさん [sage]： 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ？
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの？
エンコーディングが明確になるだ？
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
125:デフォルトの名無しさん
11/02/12 12:37:38
gitのイメージカラーってマリオ＆ルイージだよね
126:デフォルトの名無しさん
11/02/13 18:46:29
>>23
直っていない
URLﾘﾝｸ(bugs.launchpad.net)
127:methane
11/02/13 22:51:01
>>126
URLﾘﾝｸ(irclogs.ubuntu.com)
128:デフォルトの名無しさん
11/02/15 02:29:43
【bzr】Bazaarでバージョン管理 Rev 3
ｽﾚﾘﾝｸ(tech板)
129:デフォルトの名無しさん
11/02/16 16:58:30
Hg/Git/Bzr のシェアってどんなもんなんですかね？
130:デフォルトの名無しさん
11/02/16 17:08:32
Git 6/Hg 3/Bzr 1
131:デフォルトの名無しさん
11/02/16 17:18:08
Git優勢なんすね
132:デフォルトの名無しさん
11/02/16 17:20:26
>>130
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
133:デフォルトの名無しさん
11/02/16 17:35:28
URLﾘﾝｸ(qa.debian.org)
134:デフォルトの名無しさん
11/02/16 17:49:06
>>133
一面ではあると思うが参考になったthx。
135:デフォルトの名無しさん
11/02/16 22:40:17
大事なのは、
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
136:デフォルトの名無しさん
11/02/23 13:50:37.67
最近、
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
137:デフォルトの名無しさん
11/02/23 14:50:33.54
>>136
文字コードスレによれば、WindowsでDBCSが２バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
138:デフォルトの名無しさん
11/02/23 15:47:16.08
>>137
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が？前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
139:デフォルトの名無しさん
11/02/23 15:54:28.95
Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも
対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
140:デフォルトの名無しさん
11/02/23 15:56:36.88
そりゃ"Double Byte"が3バイト以上だったりしたら困るわな
141:デフォルトの名無しさん
11/02/23 16:04:56.51
2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・
142:デフォルトの名無しさん
11/02/23 16:17:51.15
>>141
DBCS=MBCSだからCP932用
UTF-16とは関係ない
143:デフォルトの名無しさん
11/02/23 16:36:34.15
UTF-16でサロゲートペア対応だから2byteじゃねーし。
144:デフォルトの名無しさん
11/02/23 17:29:00.69
>>142
あー、ごめん、Unicode策定してた連中に言ったつもりだった。
145:デフォルトの名無しさん
11/02/23 18:04:01.31
ん？
146:デフォルトの名無しさん
11/02/23 19:37:32.05
Windows対応アプリを作る場合は、APIコールの度に毎回UTF-8→UTF-16変換してW版APIを呼ぶのが正道なんだけど
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
147:デフォルトの名無しさん
11/02/23 23:20:04.23
>>141
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
148:147
11/02/23 23:21:23.77
UTF-16というか、UTF-8以外のUnicode表現。UTF-16決め打ちじゃなくて
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
149:デフォルトの名無しさん
11/02/24 23:28:17.70
文字としては、さすがにUCS-4で足りるだろうから
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
150:デフォルトの名無しさん
11/02/24 23:34:29.78
>>149
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
151:デフォルトの名無しさん
11/02/24 23:36:42.45
>>150
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
152:デフォルトの名無しさん
11/02/24 23:42:06.92
Javaって今は内部UTF-16でインターフェースは好きにできる感じじゃなかったっけ。
WindowsはUTF-16固定？
153:デフォルトの名無しさん
11/02/24 23:46:12.23
普通は内部文字コードは UCS4 じゃないの
UTF-16 は負の遺産という認識だったけど
154:デフォルトの名無しさん
11/02/24 23:49:15.38
UTF-16はサロゲートペアが気持ち悪いのでちょっと・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
155:デフォルトの名無しさん
11/02/24 23:49:40.00
つうか、後顧の憂いを残さない為には、内外共にUTF-8にしておくのがベストなんじゃ？
156:デフォルトの名無しさん
11/02/24 23:49:54.49
>>153
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
157:デフォルトの名無しさん
11/02/24 23:52:04.46
>>155
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
158:デフォルトの名無しさん
11/02/24 23:52:24.00
>>155
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
159:デフォルトの名無しさん
11/02/24 23:52:55.00
内部コードを何にするかが、バージョン管理システムにどう影響するんだ？
いい加減スレ違いだからUnicodeスレに行け。
160:デフォルトの名無しさん
11/02/24 23:53:13.04
ってか、こんな問題の関わりたくないからファイル名はバイナリだ、とかいう割り切りになってんだろうね。
161:デフォルトの名無しさん
11/02/24 23:54:28.69
>>160
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
162:デフォルトの名無しさん
11/02/24 23:57:10.63
>>156
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
163:デフォルトの名無しさん
11/02/25 00:13:29.48
プログラム用のバージョン管理システムが扱う文字の範囲なんて殆ど ascii の範疇なんだから、
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
164:デフォルトの名無しさん
11/02/25 00:16:13.76
保存用はそりゃUTF-8だろ。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
165:デフォルトの名無しさん
11/02/25 00:26:42.61
元々はWindowsでファイル名が化ける云々…というのが発端で、
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
166:デフォルトの名無しさん
11/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:デフォルトの名無しさん
11/02/25 07:25:35.98
>>166
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
168:デフォルトの名無しさん
11/02/25 07:56:03.02
>>167
内部エンコーディングの意味わかってる？
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
169:デフォルトの名無しさん
11/02/25 08:05:16.70
>>168
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね？
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね？
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね？
170:デフォルトの名無しさん
11/02/25 08:11:27.04
>>169
そこがパフォーマンス上ボトルネックになるとでも思っているのか…
171:デフォルトの名無しさん
11/02/25 08:18:17.40
>>170
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ？
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの？
172:デフォルトの名無しさん
11/02/25 08:33:17.66
>>171
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
173:デフォルトの名無しさん
11/02/25 08:39:29.22
>>172
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
３２ビットOSでは動かなくなるよ？
174:デフォルトの名無しさん
11/02/25 08:45:24.40
>>173
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの？
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは２倍になるよね？
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん？
175:デフォルトの名無しさん
11/02/25 08:50:59.41
>>174
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
176:デフォルトの名無しさん
11/02/25 09:03:22.14
>>175
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
177:デフォルトの名無しさん
11/02/25 09:39:03.80
>>176
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
178:デフォルトの名無しさん
11/02/25 10:03:21.47
>>177
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
179:デフォルトの名無しさん
11/02/25 10:23:05.55
>>178
うん、bzrの設計はおかしい。
2005年だとJavaの文字２バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
180:デフォルトの名無しさん
11/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
11/02/25 10:37:41.52
>UTF-16 は Unicode のほとんどの文字集合を表現可能で、
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の（まだ文字が割り当てられていないコードを含む）ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
182:デフォルトの名無しさん
11/02/25 10:38:27.52
>>180
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
183:デフォルトの名無しさん
11/02/25 10:38:56.90
bzrはどの分散管理よりもマルチ環境で使える
これが全て
他のは日本語環境だと使い物にならない
184:デフォルトの名無しさん
11/02/25 10:40:51.98
そっか。じゃあ俺は Git を使うわ。問題が起きた事無いし。
185:デフォルトの名無しさん
11/02/25 10:41:55.69
例えばSubversionの場合、
WindowsではUTF-16に変換してUnicode APIを呼ぶ（リポジトリ内部はUTF-8？）
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな？
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない？
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
186:180
11/02/25 10:49:26.64
>>185
subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
187:180
11/02/25 10:50:37.47
>>182
Unicodeに統一したいの？したくないの？
まったく意味が判らないよ。
188:デフォルトの名無しさん
11/02/25 11:34:29.81
ファイル名なんかよりもコミットログ、特にコミットユーザ名が一番重要。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
189:デフォルトの名無しさん
11/02/25 11:50:50.34
>>186
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では？
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな？
190:デフォルトの名無しさん
11/02/25 12:20:48.99
>>188
全部大事
全部満たしてるのがbzrだけ
191:デフォルトの名無しさん
11/02/25 12:27:11.43
>>190
日本人の人名で普通に使われている文字がbzrでは使えないよね？
192:methane
11/02/25 12:40:06.97
>>191
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
193:デフォルトの名無しさん
11/02/25 13:25:59.99
でも・・・正解が欲しいよ・・・ママン・・・
194:デフォルトの名無しさん
11/02/25 13:43:27.41
そんなものを求めたら宗教戦争に巻き込まれるだけだと思うぞ
195:デフォルトの名無しさん
11/02/25 14:51:51.55
いあ、add時のプラットフォームとエンコーディングをメタ情報に持った上でファイル名自体はバイナリとして保存、
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
196:デフォルトの名無しさん
11/02/25 14:54:01.19
>>195
よう、いいだしっぺ
197:デフォルトの名無しさん
11/02/25 15:17:44.23
もうMIMEエンコードして保持しとけよ
198:デフォルトの名無しさん
11/02/25 15:17:45.41
>>195
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの？
199:デフォルトの名無しさん
11/02/25 15:21:00.63
>>198
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか？
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
200:デフォルトの名無しさん
11/02/25 16:29:57.73
>>197
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
201:デフォルトの名無しさん
11/02/25 16:33:31.64
>>199
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
202:デフォルトの名無しさん
11/02/25 16:38:53.66
>>201
Eclipseで使えないと困っちゃうんだよねぇ・・・
203:デフォルトの名無しさん
11/02/25 16:50:04.22
>>201
それってUTF-8対応したCygwinってやつ？
てことは、WindowsでもCygwinなら化けない？
204:デフォルトの名無しさん
11/02/25 17:15:40.44
>>203
そうだよ、EUC-JPのファイル名もチェックアウトできるよ
205:デフォルトの名無しさん
11/02/25 18:45:30.52
>>180
> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが？
206:デフォルトの名無しさん
11/02/25 19:21:43.99
>>201
NTFSがUTF-16なのにどこで保存してるんだ？
セカンドストリーム？
207:デフォルトの名無しさん
11/02/25 22:31:47.81
なんか Cygwin についてごっちゃになってるっぽいので整理。
- Cygwin は 1.7 から UTF-8 Cygwin と同じような対応が入ってロケール設定がファイル名(の変換)に効くようになった。
- LANG=ja_JP.EUC-JP するとプログラムから見た場合にファイル名が EUC-JP になってるように見える。
プログラム内で EUC-JP のファイル名渡すと Cygwin API layer で UTF-16 に変換されて Wide API 経由でアクセスされる。
- Windows のファイルシステムで許可されない文字(例えば : とか)は Unicode のプライベートエリアの文字に変換される。
Cygwin 上で見る場合は逆変換されるので普通に見える。
208:デフォルトの名無しさん
11/02/25 23:10:55.47
Mercurialのファイル名問題のほんとの理由は、コア開発者の中に、
非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。
209:デフォルトの名無しさん
11/02/25 23:34:44.37
>>207
まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑
210:デフォルトの名無しさん
11/02/26 00:32:46.22
>>187
Unicode と言ったら、今は UTF-8 か UTF-32
211:デフォルトの名無しさん
11/02/26 00:39:59.28
>>210
お前の頭の中だけな。
212:デフォルトの名無しさん
11/02/26 00:41:32.04
Unicode が俺の頭の中にあったとは！
でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。
213:デフォルトの名無しさん
11/02/26 00:49:19.48
>>212
WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。
214:デフォルトの名無しさん
11/02/26 00:50:59.24
>>213
Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ
215:デフォルトの名無しさん
11/02/26 00:55:30.81
UTF-32（笑）
216:デフォルトの名無しさん
11/02/26 01:04:09.03
>>214
Servlet って Java か？
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。
っていうか、入出力って、外部エンコーディングの話してたの？
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの？
それとも内部エンコーディングっていう単語の意味がわからなかったの？
217:デフォルトの名無しさん
11/02/26 01:07:07.26
>>216
Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ
218:デフォルトの名無しさん
11/02/26 01:10:43.62
>>217
なんで？UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。
219:デフォルトの名無しさん
11/02/26 01:15:24.95
>>218
何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。
今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・
220:デフォルトの名無しさん
11/02/26 01:40:59.65
>>219
文字の符号数が固定でなくても、符号が固定長なのは処理の楽さに影響するよ。
UTF-8を処理する場合は、複数のバイト列から符号位置（序数）をデコードしたあと、
複数の序数を組み合わせて1つの文字を作る。
UTF-16やUTF-32を処理する場合は、16bit/32bitで直接符号位置（序数）が入っているから、
複数の序数を組み合わせて1つの文字を作るだけ。
UTF-8に対してUTF-16は、ASCII文字が大半を占めるときにメモリ効率が下がるという
デメリットと、処理が軽くなるというメリットがある。
ただし、CJKでは下がらないもしくは効率がよくなるケースもある。
これが UTF-16 に対する UTF-32 になると、ほとんどすべてのケースでメモリ効率が
2倍近く悪くなる上に、サロゲートペアの処理は無くなるものの、それ以外の結合文字の
問題はなくならないから処理はほとんど軽くならない。
20世紀に規格が決まったJavaだけでなく、2002年の.NET、2005年のQt4もUTF-16を
選んでいるのは、それなりにメリットがあるから。
221:デフォルトの名無しさん
11/02/26 01:49:29.33
>>220
それは今更 UTF-16 を使う理由にはならないよね
何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?
222:デフォルトの名無しさん
11/02/26 02:01:08.43
ご家庭用パソコンにメモリ4GBとかHDD2TBとかいう時代にメモリ効率はないわ～
文字列が可変長なんだから、文字も可変長になっててどこがいけないのか？
UTF-8マンセー！
223:デフォルトの名無しさん
11/02/26 02:01:33.18
>>221
サロゲートペアを考慮する必要があるケースって、文字単位で処理をしたい
場合だろうけど、UTF-32にしたって結合文字や異字体セレクタを扱う必要が
あるから、サロゲートペアの処理が入っても複雑さは殆ど変わらない。
もともと内部エンコーディングの話だからバイトオーダーの違いは無視できる。
CJKの文字列の中でも数字やアルファベットが多数含まれているが、
UTF-8だと3バイトでUTF-16だと2バイトで済む文字も多数あるので、
CJKでは容量のオーバーヘッドは充分小さい。
そして、UTF-16だとほとんどの文字が2バイトで最悪4バイトなのに対して、
UTF-32だと全部の文字が4バイトなので、2倍近くに容量が膨らむ。
UTF-16は過去の技術じゃない。
あと、なんで内部エンコーディングにそんなに拘るの？
もし bzr を dis るネタにしたいのであれば、FedoraでもUbuntuでもDebianでも
PythonがunicodeをUTF-32で扱ってるから、完全に筋違いだよ？
むしろ、そういった環境で長いファイル名をたくさん使うとメモリ効率が
悪いってdisるべき。
224:デフォルトの名無しさん
11/02/26 02:03:50.56
「UTF-16 は UTF-8 に比べてここが良いんですよ！」
「え、UTF-8 の方が良い部分がある? いやいや UTF-16 だって UTF-32 に比べたらマシですよ」
「UTF-16 は UTF-32 に比べたらここが良いんですよ！」
「え、UTF-32 の方が良い部分がある? いやいや UTF-16 だって UTF-8 に比べたらマシですよ」
225:デフォルトの名無しさん
11/02/26 02:07:14.76
肝心の UTF-16 は中途半端なだけで何のメリットも無くて残念
226:デフォルトの名無しさん
11/02/26 02:12:39.15
>>222
俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。
URLﾘﾝｸ(practical-scheme.net)
227:デフォルトの名無しさん
11/02/26 02:20:15.47
>>224
俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。
228:デフォルトの名無しさん
11/02/26 02:22:47.15
いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。
CJKの当事者としてもうちょっと勉強しようぜ。
229:デフォルトの名無しさん
11/02/26 02:22:50.71
>>227
拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ
230:デフォルトの名無しさん
11/02/26 02:26:01.13
>>228
『1コードポイントは固定長』という便利な表現をこのスレで学んだからな
231:デフォルトの名無しさん
11/02/26 02:45:02.44
とりあえずUTF-8なCygwinなら化けないようなので、
hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ？ そうでもない？
IDEからCygwinのコマンド使ってもらえばオールオッケー？
232:デフォルトの名無しさん
11/02/26 02:46:54.04
cygwinからとかまるで使い物にならんな
233:デフォルトの名無しさん
11/02/26 02:49:11.61
ちなみにこのスレッドの dat ファイルのサイズは UTF-8 で 113564 bytes だけど、
UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。
日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・
234:デフォルトの名無しさん
11/02/26 02:58:37.03
GC付きのスイーツな言語処理系しか触ったことなくて、
文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。
ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ
>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよｗｗ
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよｗｗｗ
235:デフォルトの名無しさん
11/02/26 03:06:04.80
>>234
何でこんな簡単な話を理解出来ない振りをするのか分からんけど、
1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?
それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・
236:デフォルトの名無しさん
11/02/26 03:08:47.02
5. 元データが CJK 以外の場合だとどうなると思う?
237:デフォルトの名無しさん
11/02/26 03:13:01.59
そもそも、utf-8 vs utf-16 じゃなくて utf-8 or utf-32 vs utf-16 という
話だったと思うんだが。
utf-8 : utf-16 = 1:1.1～2
utf-16 : utf-32 = 1:1.9～2
つまり、utf-8とutf-16の効率の差よりも、utf-16とutf-32の差のほうが大きい。
utf-8 < utf-16 << utf-32
utf-8 と utf-16 の差をみてutf-16が非効率だと言うなら、utf-32はもっと
使いものにならない。
238:デフォルトの名無しさん
11/02/26 03:16:53.52
>>237
>>224
ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ
239:デフォルトの名無しさん
11/02/26 03:18:52.01
>>238
utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。
240:デフォルトの名無しさん
11/02/26 03:20:38.04
横からごめんよ。
よく分からんが、ここで争ってる文字コードは、どこで使う文字コード？
バージョン管理システム内だけで使う文字コードじゃないの？
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話？
241:デフォルトの名無しさん
11/02/26 03:21:53.26
>>240
なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。
242:デフォルトの名無しさん
11/02/26 03:23:17.21
>>239
俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。
UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。
243:デフォルトの名無しさん
11/02/26 03:25:05.29
>>240
>バージョン管理システム内だけで使う文字コードじゃないの？
つ >>164
244:デフォルトの名無しさん
11/02/26 03:25:40.70
>>242
この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。
245:デフォルトの名無しさん
11/02/26 03:25:56.41
>>241
ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか？
246:デフォルトの名無しさん
11/02/26 03:28:47.22
>>244
効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙
247:デフォルトの名無しさん
11/02/26 03:29:23.71
>>243
あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。
248:デフォルトの名無しさん
11/02/26 03:30:07.68
>>247
そう、ぶっちゃけどうでも良いのです。
249:デフォルトの名無しさん
11/02/26 03:30:08.18
つまり、ファイル名をunicodeで扱うかバイト列で扱うかという話に、
何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。
250:デフォルトの名無しさん
11/02/26 03:32:09.41
>>249
そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。
251:デフォルトの名無しさん
11/02/26 03:32:49.71
>>246
効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8
効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。
252:デフォルトの名無しさん
11/02/26 03:36:34.42
ファイル名なんて、システム依存なんだから、
文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて？
253:デフォルトの名無しさん
11/02/26 03:39:34.62
>>251
結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ
254:デフォルトの名無しさん
11/02/26 04:02:39.82
utf8もutf16もutf32もサロゲートペア使って表せる範囲は全て同じでしょ？
基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの？
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…？
あぁ、結合文字とかも考えると、もっとめんどくさいのか…
255:デフォルトの名無しさん
11/02/26 06:50:22.82
utf16で盛り上がっているようですが、NTFSはutf16ではありません。ucs-2です
256:デフォルトの名無しさん
11/02/26 06:58:56.83
何その主張？
utf16じゃなくてutf-16とでも言いたいの？
それともucs-2はunicodeじゃないと言いたいの？
257:デフォルトの名無しさん
11/02/26 07:28:10.17
>>256
ｽﾚﾘﾝｸ(tech板:466-468番)
466 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:48:00
（略）
むしろ正規化されてないのはNTFSの方で、NTFSでは1つのファイル名でNFCとNFDの混在すら可能。
Windowsの日本語IMEはNFCしか吐かないので、NTFSはNFCで正規化されていると誤解されやすい
んだけど、ファイル名としてNFDな文字列やNFCとNFDが混在した文字列を指定した場合に、NTFS
で保存されるファイル名がNFCに正規化されるような事はない。（これは実際に試せば分かる）
（略）
467 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 21:57:34
NTFSのそれは (WCHAR)0 を含まない WCHAR列に過ぎないんじゃなかったっけ。
と思ったけど大文字小文字の話が合った。
468 名前：デフォルトの名無しさん [sage]： 2010/11/27(土) 22:05:47
WCHARも16ビット、32ビットあって単純じゃないのよね。
NTFSも本当にUTF-16なのか？という疑問もあるらしいし。
URLﾘﾝｸ(jp.rubyist.net)
258:デフォルトの名無しさん
11/02/26 07:30:25.22
>>256
ｽﾚﾘﾝｸ(tech板:472番)
472 名前：デフォルトの名無しさん [sage]： 2010/11/28(日) 03:40:53
>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。
259:デフォルトの名無しさん
11/02/26 07:31:18.33
>>257
つ UTF-16 == UCS/Unicode Transformation Format 16
260:デフォルトの名無しさん
11/02/26 10:19:28.28
内部コードがUTF-いくつなんてどうでもいいだろ。
外から見て差が出るところを話そうぜ……。
261:デフォルトの名無しさん
11/02/26 10:30:56.66
>>260
うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの？
262:デフォルトの名無しさん
11/02/26 10:34:13.89
bzrのアンチ活動とか不毛すぎるだろ……
263:デフォルトの名無しさん
11/02/26 10:37:46.68
>>262
svn/hgはメッセージ日本語化されているよ
264:デフォルトの名無しさん
11/02/26 10:41:05.75
自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが
日本語化されていると嬉しいかもしれんなぁ。
265:デフォルトの名無しさん
11/02/26 10:55:44.74
>264
素人がコンソールで使うわけ無いだろ。GUI必須。
266:デフォルトの名無しさん
11/02/26 10:55:58.34
どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
267:デフォルトの名無しさん
11/02/26 11:13:32.83
>>266
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
268:methane
11/02/26 12:12:01.68
>>261
そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
269:デフォルトの名無しさん
11/02/26 12:42:29.67
>>268
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね？
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね？
270:methane
11/02/26 15:15:05.28
>>269
前者は何とかする予定。
後者はさすがに無理ゲー（勝手にdiffの出力を変えたらpatchが動かない）なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
271:デフォルトの名無しさん
11/02/26 15:23:25.20
>>270
ということは、bzrのパッチもLinuxではロケール依存なのですね？
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね？
272:methane
11/02/26 15:37:40.65
>>271
何処をどう読めばそうなるんだろう…？
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
273:methane
11/02/26 15:38:21.18
あ、間違えた。
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
274:デフォルトの名無しさん
11/02/26 15:42:10.39
bzrのcmd.exeの標準出力はCP932だよね？
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか？
275:methane
11/02/26 15:46:43.42
>>274
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
276:デフォルトの名無しさん
11/02/26 15:50:34.51
>>275
そのプラグインとは？
277:methane
11/02/26 16:18:29.23
>>276
URLﾘﾝｸ(gigo-ice.org)