1 :デフォルトの名無しさん2011/01/20(木) 12:26:04
バージョン管理システムについて語りましょう
●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
8 :デフォルトの名無しさん2011/01/20(木) 12:35:22
589 名前:デフォルトの名無しさん [sage]: 2010/12/12(日) 01:31:11
お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/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
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024
592 名前:デフォルトの名無しさん [sage]: 2010/12/12(日) 01:42:16
ここも
http://www23.atwiki.jp/selflearn/pages/55.html
593 名前:デフォルトの名無しさん [sage]: 2010/12/12(日) 01:44:57
あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474
お前らこの「svnが遭遇してきた問題点とその解決策」を共有したいのでどこに記述あるか教えてください
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/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
こっちでいいじゃん
http://d.hatena.ne.jp/hnw/20081024
592 名前:デフォルトの名無しさん [sage]: 2010/12/12(日) 01:42:16
ここも
http://www23.atwiki.jp/selflearn/pages/55.html
593 名前:デフォルトの名無しさん [sage]: 2010/12/12(日) 01:44:57
あとここ
http://hibari.2ch.net/test/read.cgi/tech/1251208950/466-474
23 :methane2011/01/25(火) 16:58:26
>>8
http://svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup
ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。
http://svn.apache.org/viewvc/subversion/trunk/notes/unicode-composition-for-filenames?view=markup
ちなみに、2月リリースのbzr-2.3のベータ版ではもう直ってるっぽい。
24 :デフォルトの名無しさん2011/01/26(水) 06:51:31
>>23
これで「社会が憎い.properties」が使えるわけですね。
これで「社会が憎い.properties」が使えるわけですね。
25 :デフォルトの名無しさん2011/01/26(水) 10:39:24
>>23-24
誰得アプリに磨きがかかったのですね
誰得アプリに磨きがかかったのですね
26 :デフォルトの名無しさん2011/01/26(水) 11:49:05
>>25
リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。
・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・デザイナ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。
リポジトリの構造や、ブランチ操作の手軽さはMercurialの方が優位だと思うが、弊社の以下の状況はBazaar優位になっています。
・PM佐藤は「英語わからんし」とつぶやいて、日本語ファイル名を作る。
・PG田中はマカーなので、Windowsは手が汚れると言って触りもしない。
・PG茶谷はLinuxでvimを使うことだけがアイデンティティ。
・デザイナ鈴木はWindows以外は分からないと言って、Macintosh OS Xを直視もしない。
28 :methane2011/01/26(水) 12:28:18
>>26
リポジトリの構造ってMercurial優位だっけ?
bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
リポジトリの構造ってMercurial優位だっけ?
bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
29 :デフォルトの名無しさん2011/01/26(水) 12:36:33
>>28
表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。
・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。
GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。
表現方法が悪いのかも知れないけど、以下の理由でMercurialの方が優位だと思う。
・チェンジセットの関係が木構造で操作が直感的。
・名前無しブランチがあるので、ブランチを作るのが容易。
・名前付ブランチも、まとめてpush/pullできる。
GitもBazaarもブランチは直線的で、分岐するのには操作がいる。clone、push、pullもブランチ単位。
特にBazaarは、ブランチの扱いでディレクトリ配置を意識する必要がある。
30 :methane2011/01/26(水) 12:44:09
>>29
あぁ、 .bzr とか .hg 内部のファイル/データ構造という意味じゃないのね>リポジトリの構造
そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
あぁ、 .bzr とか .hg 内部のファイル/データ構造という意味じゃないのね>リポジトリの構造
そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
31 :デフォルトの名無しさん2011/01/26(水) 12:51:50
>>28
> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い
bzrはコピーをサポートしている?
FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない?
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか?
> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
cygwin
あと、例の拡張
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
進化している
マイナーチェンジで基本は全く変わっていないけど
> bzrの方がファイル数少なくて容量小さいし、
hgはコピーをサポートしていて、ファイルの移動はコピーと削除だから
大幅にディレクトリ構成を変更した場合、必然的にリポジトリがでかくなる。
あまりにも大幅な構成の変更の場合、convertをした方が良い
bzrはコピーをサポートしている?
FATの場合、でかいファイルの方がフラグメントやらで都合が悪くない?
gitの場合、packするしないはユーザの自由だが、bzrは勝手にパックしちゃうのか?
> やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
cygwin
あと、例の拡張
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
進化している
マイナーチェンジで基本は全く変わっていないけど
32 :methane2011/01/26(水) 13:02:40
>>31
bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。
FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。
>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう?
bzrはコピーは今はサポートしていない。
代わりに、移動はサポートしていて移動しても容量は増えない。
FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
パックは10、100、1000コミットごとに自動で行われる。
>cygwin
>あと、例の拡張
Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
例の拡張ってなんだろう?
33 :デフォルトの名無しさん2011/01/26(水) 13:12:22
>>32
> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。
2GB制限は?
> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう?
当然知っているでしょ?
MAX_PATHのことを言っているんでしょ?
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張
> >>31
> bzrはコピーは今はサポートしていない。
> 代わりに、移動はサポートしていて移動しても容量は増えない。
>
> FATの場合、クラスタのアライメント差があったり、ディレクトリエントリが
> ツリーじゃなくて配列だから、小さいファイルが沢山ある方が効率が悪い。
> パックは10、100、1000コミットごとに自動で行われる。
2GB制限は?
> >cygwin
> >あと、例の拡張
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
> 例の拡張ってなんだろう?
当然知っているでしょ?
MAX_PATHのことを言っているんでしょ?
ANSI APIを使うという方針なんだから仕方がない。
それを横取りしている拡張
34 :methane2011/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の変換をしていただけで、 "\\?\" は使ってなかった。
bzr関連のブランチを格納しまくってるshared repositoryの中をのぞいてみたら、
pack数が12個で最大のものが31MBだから、ソースコード管理では2GB制限は
気にしないで良さそう。動画ファイルとか大容量のファイルの扱いは確かに苦手。
MAX_PATHはANSIとは直交した制限で、CreateFileWとか使っても同じUTF-16の
コードポイント数が制限を受ける。
この制限を回避するためには "\\?\c:\" みたいな書きかたでWin32APIのチェックを
スルーしてファイルシステムにアクセスしないといけないんだけど、これをやると
カレントディレクトリとか一切使えなくなる。
例の拡張ってのが、もしfix-utf8の事を言っているのであれば、僕が昔触ってた時は
utf8<=>utf16の変換をしていただけで、 "\\?\" は使ってなかった。
36 :デフォルトの名無しさん2011/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が洗練されているようには思えない。
>そこらへんでどちらが優位とかは完全に個人の感覚に依存しちゃうから賛同も反論もしない。
リビジョン番号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 :デフォルトの名無しさん2011/01/26(水) 13:59:05
>>36の続きだが、Bazaarの「リポジトリ」もあまり良いコンセプトに思えない。
準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。
「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。
後から「リポジトリ」を使うこともできるが、移行作業はいる。
準備無しにBazaarでブランチを切ると、ディスク占有サイズが倍増する。
「リポジトリ」を作っておけば、ブランチを切っても実ファイルはシェアするが、事前準備がいる。GitやMercurialには不要な作業。
後から「リポジトリ」を使うこともできるが、移行作業はいる。
38 :デフォルトの名無しさん2011/01/26(水) 14:07:06
>>36
Git (3ステップ):
git checkout -b NewBranch 0b70750b
[編集]
git commit -m "以前のバージョンから分岐"
Git (3ステップ):
git checkout -b NewBranch 0b70750b
[編集]
git commit -m "以前のバージョンから分岐"
39 :デフォルトの名無しさん2011/01/26(水) 14:09:15
>>36
git checkout -b NewBranch 0b70750b
git checkout -b NewBranch 0b70750b
40 :methane2011/01/26(水) 14:12:49
>>35
>hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
>って、これも知っているよね?
bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
という制限もない。
>もう1つの拡張の方も横取りしている。
>パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
>そこがANSI APIになっている。
もう一つって、win32なんちゃらの事かな?
最近hg使ってないから最近の事情に疎くて、、、またhg使い始める予定だから調べとこ。
一応言っておくけど、 hg のリポジトリフォーマットが効率悪くて使い物にならないとか
言ってもなければ思ってもないよ。
>>26 を hg のリポジトリフォーマットがbzrより優秀と誤読したから反論しただけ。
リポジトリフォーマットは hg, git, bzr 全部、ソースコード管理目的では十分な効率をしている。
hgでMAX_PATHが問題になるのもレアケースで、僕が使ってる限り問題になったことはない。
>hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
>って、これも知っているよね?
bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
という制限もない。
>もう1つの拡張の方も横取りしている。
>パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
>そこがANSI APIになっている。
もう一つって、win32なんちゃらの事かな?
最近hg使ってないから最近の事情に疎くて、、、またhg使い始める予定だから調べとこ。
一応言っておくけど、 hg のリポジトリフォーマットが効率悪くて使い物にならないとか
言ってもなければ思ってもないよ。
>>26 を hg のリポジトリフォーマットがbzrより優秀と誤読したから反論しただけ。
リポジトリフォーマットは hg, git, bzr 全部、ソースコード管理目的では十分な効率をしている。
hgでMAX_PATHが問題になるのもレアケースで、僕が使ってる限り問題になったことはない。
41 :methane2011/01/26(水) 14:13:42
>>36-37
つbzr-colo
つbzr-colo
42 :デフォルトの名無しさん2011/01/26(水) 14:53:47
>>41
何それ?
何それ?
44 :methane2011/01/26(水) 18:32:36
>>42
簡単に言えば、gitみたいな名前付きブランチを実現するもの。
bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。
>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる(現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える)
簡単に言えば、gitみたいな名前付きブランチを実現するもの。
bzr自体は作業ツリー、ブランチ、リポジトリを分離して自由に構成できるけど、
逆に自由すぎるのが面倒なので、1リポジトリ, 複数のブランチ、1つの作業ツリーの
組み合わせを git のように扱えるようにしてくれるもの。
>>36 で言えば、
bzr colo-branch -r30 NewBranch
の1ステップになる(現在のブランチ=OldBranchのr30からNewBranchを作って、
作業ツリーを新しいブランチのチェックアウトに切り替える)
45 :デフォルトの名無しさん2011/01/26(水) 19:00:02
>>44
> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。
\ ∩─ー、 ====
\/ ● 、_ `ヽ ======
/ \( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
、 (_/ ノ /⌒l
/\___ノ゙_/ / =====
〈 __ノ ====
\ \_ \
\___) \ ====== (´⌒
\ ___ \__ (´⌒;;(´⌒;;
\___)___)(´;;⌒ (´⌒;; ズザザザ
> >>42
> 簡単に言えば、gitみたいな名前付きブランチを実現するもの。
\ ∩─ー、 ====
\/ ● 、_ `ヽ ======
/ \( ● ● |つ
| X_入__ノ ミ そんな餌で俺様が釣られクマ――
、 (_/ ノ /⌒l
/\___ノ゙_/ / =====
〈 __ノ ====
\ \_ \
\___) \ ====== (´⌒
\ ___ \__ (´⌒;;(´⌒;;
\___)___)(´;;⌒ (´⌒;; ズザザザ
51 :methane2011/01/27(木) 00:47:49
>>50
うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、
>>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて
いいよね。
うん、で、今は内部構造じゃなくてワークフローの話をしているんだから、
>>44 の発言って別に間違ってないよね。 >>45-47 の突っ込みは気にしなくて
いいよね。
56 :methane2011/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にも
なっている。
だから俺は >>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にも
なっている。
59 :デフォルトの名無しさん2011/01/27(木) 07:54:07
>>56
> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。(作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い
> 俺はsvnやbzrに慣れているから、ブランチがディレクトリにひもづいている方が
> 安心できる。(作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
大量のごみブランチが発生するのは害でしかない
マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
ブランチとやらがbzrの売りらしいが、
大規模コミュニティの開発では何のメリットも無い
62 :methane2011/01/27(木) 08:07:51
>>59
> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ(ディレクトリ)にあった方が、「あの作業中のブランチどこおいてたっけ?」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。
> github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
意味が分からない。
リポジトリのフォークって個人所有のブランチ切る以上の意味があるの?
> 大量のごみブランチが発生するのは害でしかない
> マージし忘れなのか、興味が無くなって放置されているのか、見分けが出来ない
だからこういう個人の主観による優劣で議論する気ないんだってば。
**俺は** 目に付くところ(ディレクトリ)にあった方が、「あの作業中のブランチどこおいてたっけ?」
ってならないし、本当に要らないものを整理する気になるから好きってだけで、
別にbzrはそれを強制してないから、 >>59 が bzr を使うときには俺と違う使い方をすればいい。
> github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
意味が分からない。
リポジトリのフォークって個人所有のブランチ切る以上の意味があるの?
66 :デフォルトの名無しさん2011/01/27(木) 09:01:24
>>62
> **俺は** 目に付くところ(ディレクトリ)にあった方が、「あの作業中のブランチどこおいてたっけ?」ってならない
Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ?」と考える必要がある。
目につくところに無いのは、Bazaarとしか思えない。
> **俺は** 目に付くところ(ディレクトリ)にあった方が、「あの作業中のブランチどこおいてたっけ?」ってならない
Gitはブランチの一覧ができる。
Mercurialはブランチやヘッドの一覧ができる。
Bazaarはディレクトリを見て、「これブランチだっけ?」と考える必要がある。
目につくところに無いのは、Bazaarとしか思えない。
67 :デフォルトの名無しさん2011/01/27(木) 09:05:55
>>62
> > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
> 意味が分からない。
> リポジトリのフォークって個人所有のブランチ切る以上の意味があるの?
意味が分からない
「個人所有のブランチ」って何?
> > github、bitbucketのようにリポジトリのフォークのコストが少ない方がメリットが大きい
> 意味が分からない。
> リポジトリのフォークって個人所有のブランチ切る以上の意味があるの?
意味が分からない
「個人所有のブランチ」って何?
68 :デフォルトの名無しさん2011/01/27(木) 09:19:32
>>62
> だからこういう個人の主観による優劣で議論する気ないんだってば。
「個人の主観」ではなく、VCS運用の基本ではないか。
Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。
Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。
> だからこういう個人の主観による優劣で議論する気ないんだってば。
「個人の主観」ではなく、VCS運用の基本ではないか。
Git、Mercurialとも基本機能は単純だが、プロジェクト毎に方法論を確立している。
Bazaarはオープンソースでの実績があまりにも乏しいのもあって、方法論が確立しているように見えない。
69 :methane2011/01/27(木) 09:35:19
>>66
だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。
**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ?」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。
>>67
自分がpushできるブランチ
>>68
個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
ワークフローか?個人が便利に使えたらそれで良いじゃん。
だから **俺は** って言ってるじゃん。別にbzrがgit,hgより優れてるなんて言ってないよ。
**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
「これブランチだっけ?」なんて考えないし、そもそもコミットしてないデバッグ目的の変更や、
addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
そこに残しているの。
bzrならこんな使い方もできるというだけで、一般的にこの方法が優れているなんて思ってないし、
bzrもこの使い方を強制しているわけじゃない。
>>67
自分がpushできるブランチ
>>68
個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
ワークフローか?個人が便利に使えたらそれで良いじゃん。
70 :デフォルトの名無しさん2011/01/27(木) 09:40:39
>>69
> >>68
> 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
> ワークフローか?個人が便利に使えたらそれで良いじゃん。
bzrは個人でしか使えないという認識で良いのですね?
> >>68
> 個人の作業中のデータを個人のPCのどこに置くのが便利かなんてプロジェクトで確立するべき
> ワークフローか?個人が便利に使えたらそれで良いじゃん。
bzrは個人でしか使えないという認識で良いのですね?
73 :methane2011/01/27(木) 09:44:07
>>70
そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、
最初からローカル作業の話なんだけど?
開発サイトでのブランチの管理と、ローカルでの作業ツリー+ブランチの管理は別物。
そもそもこの議論の発端が俺の 「ブランチがディレクトリにひもづく」 発言なんだから、
最初からローカル作業の話なんだけど?
開発サイトでのブランチの管理と、ローカルでの作業ツリー+ブランチの管理は別物。
75 :デフォルトの名無しさん2011/01/27(木) 10:00:45
>>69
> そもそもコミットしてないデバッグ目的の変更や、
> addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
> そこに残しているの。
Subversionの欠点をそのまま踏襲しているのか?
> そもそもコミットしてないデバッグ目的の変更や、
> addしないメモ用ファイルやテストデータファイルなんかも、ブランチごとに作業ツリー作って
> そこに残しているの。
Subversionの欠点をそのまま踏襲しているのか?
76 :デフォルトの名無しさん2011/01/27(木) 10:20:06
>>69
>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。
>**俺は** ブランチ置き場のディレクトリを作ってるからディレクトリ見て
GitやMercurialと比較して、Bazaarは運用にmethane氏のようなコツがいるわけだね。
85 :methane2011/01/27(木) 12:41:47
>>83
単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという
ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って
思われても仕方ないな。すまん。
単に、ブランチごとに作業ツリー作るのが楽と感じる人もいるんだよという
ことが言いたかっただけなんだが、 >>56 を見るとそれが bzr の特徴って
思われても仕方ないな。すまん。
98 :デフォルトの名無しさん2011/01/27(木) 15:53:11
>>56
> (作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
これって、Trac/Redmineを使えば良いだけでは?
> (作業中のブランチを数か月放置して復帰するときにやりかけの
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
これって、Trac/Redmineを使えば良いだけでは?
113 :デフォルトの名無しさん2011/01/28(金) 11:04:08
>>28
> >>26
> リポジトリの構造ってMercurial優位だっけ?
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/Win32LongFileNamesExtension
> >>26
> リポジトリの構造ってMercurial優位だっけ?
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/Win32LongFileNamesExtension
114 :デフォルトの名無しさん2011/01/28(金) 11:14:29
>>32
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65
> Windowsで \\.\ を使ってファイルシステムに直アクセスするのかな。頑張るなぁ。
https://bitbucket.org/remleduff/win32lfn/src/a21c5be76398/src/win32lfn.py#cl-65
115 :デフォルトの名無しさん2011/01/28(金) 11:35:20
>>28
> >>26
> リポジトリの構造ってMercurial優位だっけ?
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/fncacheRepoFormat#Hashing_of_long_paths
> Paths inside the store that would be longer than 120 chars are now hash encoded.
> >>26
> リポジトリの構造ってMercurial優位だっけ?
> bzrの方がファイル数少なくて容量小さいし、やたら長いパスのファイル名を
> 作ってWindowsの制限に引っかかる事がないので良いと思ってたんだけど、
> いつの間にか新しいリポジトリフォーマットが出てきてたのかな。
http://mercurial.selenic.com/wiki/fncacheRepoFormat#Hashing_of_long_paths
> Paths inside the store that would be longer than 120 chars are now hash encoded.
126 :デフォルトの名無しさん2011/02/13(日) 18:46:29
127 :methane2011/02/13(日) 22:51:01
332 :デフォルトの名無しさん2011/04/25(月) 23:28:01.24
>>331
つ>>8
svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。
つ>>8
svnも問題あり、というよりマルチプラットフォームで問題ないものは無い。
333 :デフォルトの名無しさん2011/04/25(月) 23:28:50.00
>>332
それは既にパッチあるだろ
それは既にパッチあるだろ
2 :デフォルトの名無しさん2011/01/20(木) 12:26:45
●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
Git 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1254838551/
Git 2 [プログラム板]
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
【分散型バージョン管理】 Mercurial 【hg】
http://hibari.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://hibari.2ch.net/test/read.cgi/tech/1265951333/
3 :デフォルトの名無しさん2011/01/20(木) 12:27:35
●関連サイト
CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx
●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
git チュートリアル (バージョン 1.5.1 以降用)
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx
●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
git チュートリアル (バージョン 1.5.1 以降用)
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
5 :デフォルトの名無しさん2011/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)
↓
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 :デフォルトの名無しさん2011/01/20(木) 12:31:24
5. GUIやEclipseでの利用を重視しますか?
│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか?
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
(チェンジセット: 4:ae4c01d241ab)
│
├(YES)→ Mercurialをおすすめします。TortoiseHgとMercurialEclipseの開発が進んでいます。
(NO)
↓
6. シンプルな操作がお好みですか?
│
├(YES)→ Mercurialをおすすめします。チェンジセットの指定方法や管理方法が簡単です。
(NO)
↓
Gitをおすすめします。高速で高度な管理機能が充実しています。Linux環境下のCLIでは安定した挙動になっています。
(チェンジセット: 4:ae4c01d241ab)
7 :デフォルトの名無しさん2011/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が必要。
皆様のレスを読んだ上で、再度、大雑把に特性をまとめてみた。
Mercurial:
・一つのリポジトリで複数のブランチが扱える。
・分岐時は、無名ブランチが自動で切られる。名前付ブランチもつくる事ができるが、目印なので必須では無い。
・ブランチ内のチェンジセットは木構造に並ぶ。
・分岐したブランチは、元のブランチに依存する。あるブランチ内のチェンジセットを消すと、別のブランチにある子孫チェンジセットも消える。
・複数のリポジトリで変更を行いpushしても、分岐しているので衝突はしない。ただし、解消が要求されるmulti-head状態になるので、先にpullが望ましい。
Git:
・一つのリポジトリで複数のブランチが扱える。
・分岐時に、ブランチ名を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のリポジトリで変更を行いpushすると、衝突が発生する。先にpullが必要。
Bazaar:
・ブランチだけで運用を行える。リポジトリを作ると、複数ブランチでデータを共有して省スペース、ブランチ作成などの高速化ができる。
・分岐時に、ブランチのディレクトリ配置を考える必要がある。
・ブランチ内のチェンジセットは直線上に並ぶ。
・マージするときは、自分のリポジトリのコミットをメインライン、他のリポジトリのを傍流として記録。
・ブランチは、他のブランチのコピー。あるブランチを削除しても、そのブランチから分岐したブランチは影響を受けない。
・複数のブランチで変更を行いpush/pullすると、衝突が発生する。先にpullが必要。
10 :デフォルトの名無しさん2011/01/20(木) 15:14:59
749 名前:デフォルトの名無しさん [sage]: 2010/12/30(木) 19:23:52
append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。
http://twitter.com/#!/methane/status/11806331434442752
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。
append_revisions_only
“True”に設定されていればリビジョンはログにのみ追加され、削除されません。
この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
通常これは bzr init --append-revisions-only によって設定されます。
http://twitter.com/#!/methane/status/11806331434442752
append_revisions_only = True に設定したブランチでは、連番のリビジョン番号が固定され、ID替わりに使えること。
中央リポジトリ上のブランチはこの設定がおすすめ。
11 :デフォルトの名無しさん2011/01/20(木) 15:15:43
751 名前:デフォルトの名無しさん [sage]: 2010/12/30(木) 19:46:58
もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、
履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。
通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた
細かいリビジョンを無視して、それをメインラインにマージしたコミット1つにまとめて表示できる。
なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な1つのコミットにするみたいな
作業が要らない。
(もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い)
なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは
メインラインはローカルブランチに、中央ブランチはサブラインになって、それを 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
もうちょっと詳しく言うと、bzrはgitやhgと違って、「メインライン」という概念があって、
履歴のウチ並列して存在するラインの片方がメイン、残りがマージされたブランチという扱いになる。
通常はメインラインのウチのリビジョンだけを表示することで、別ブランチで開発中にコミットされた
細かいリビジョンを無視して、それをメインラインにマージしたコミット1つにまとめて表示できる。
なので、ローカルで作業中に作ったゴミみたいなコミットをまとめて綺麗な1つのコミットにするみたいな
作業が要らない。
(もちろん、メインラインを無視して、全ブランチが同等という運用をしても良い)
なんだけど、だれかがローカルのブランチから中央のブランチをマージすると、そのローカルでは
メインラインはローカルブランチに、中央ブランチはサブラインになって、それを 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 :デフォルトの名無しさん2011/01/20(木) 18:04:24
そろそろ、zipを超えるバージョン管理システムがでるかな?
13 :デフォルトの名無しさん2011/01/20(木) 18:44:34
それならzipよりもmkdirっていうバージョン管理システムの方がずっと強い
14 :デフォルトの名無しさん2011/01/20(木) 22:46:02
しばらく見てなかったけどJGitが、結構使えるようになってるな。
JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも
日本語ファイル名も含めて今のところ相互運用に問題は無い。
まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in
に頼らないといけないところが難点。EGit の UI は悪くないけどね。
JVM上で動くので、WindowsやLinuxでも、UTF-8環境の native Gitとでも
日本語ファイル名も含めて今のところ相互運用に問題は無い。
まだ実装されてない機能もあるし、GUIで扱うなら eclipse のEGit plug-in
に頼らないといけないところが難点。EGit の UI は悪くないけどね。
16 :デフォルトの名無しさん2011/01/21(金) 00:10:52
インストールすると自動的にhomeに公開、ダウンロード、音楽、ビデオ、デスクトップ、
文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ
バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな
がいします。
文書、テンプレート、画像、なんてディレクトリが作られちゃうんで是非ともutf8のマルチ
バイト文字列のファイル・ディレクトリ名をきちんと操作・バージョン管理できるよう、おな
がいします。
17 :デフォルトの名無しさん2011/01/21(金) 00:43:44
他人と共同作業じゃなくて、自分用のバックアップ目的で使うには、Bazaarが最強との結論に達した。
18 :デフォルトの名無しさん2011/01/21(金) 00:55:06
俺は個人で使うのはgit、他人と共同作業で使わせるのはbzrという結論になった
本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど
本当は一つにしたかったし、もし無理矢理一つにするんだったらhgを選んだろうけど
19 :デフォルトの名無しさん2011/01/21(金) 01:41:43
前スレでTeam Foundation Server使用したことある人がいたようなので
使用感はどんな感じか聞いてみたい。
特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。
Perforceの対抗馬になるようなら嬉しいんだけど
使用感はどんな感じか聞いてみたい。
特に大きなリソースを扱うプロジェクトでのパフォーマンスなど。
Perforceの対抗馬になるようなら嬉しいんだけど
20 :前スレ9892011/01/21(金) 23:57:50
>>19
それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。
まだホワイトペーパー(http://download.microsoft.com/download/A/C/5/AC56DA05-5AEA-4118-B2F9-83C4E70834F1/TFS2010_SCM.pdf)
しかまだ見てないです。ちなみにシェルブ機能の紹介はP.57にあるね。
(ここから下は全部憶測)
個人的には、そもそもIIS+ASP.NET+SharePoint+MSSQLが要るという時点で、パフォーマンスはあまり期待してなかったり。
少なくとも、DBサーバーをインストールするマシンは十分なI/O性能を確保しないと悲惨なことになると思う。
その辺は伝統的な3層クラサバとまんま同じノウハウが適用できる(というか必要になる)ハズ。
あとは評価してみないことには分からないけど、ウチの場合、100MB近いMDBを数十個扱う予定なので、
その結果分かったことがあれば、ここに書くよ(忘れてなければ……)。
それを書いたのは俺だが……すまん、実務ではまだ使ってないんよ。今年中にはVSSからの移行先としてTFS2010を評価する予定だけど。
まだホワイトペーパー(http://download.microsoft.com/download/A/C/5/AC56DA05-5AEA-4118-B2F9-83C4E70834F1/TFS2010_SCM.pdf)
しかまだ見てないです。ちなみにシェルブ機能の紹介はP.57にあるね。
(ここから下は全部憶測)
個人的には、そもそもIIS+ASP.NET+SharePoint+MSSQLが要るという時点で、パフォーマンスはあまり期待してなかったり。
少なくとも、DBサーバーをインストールするマシンは十分なI/O性能を確保しないと悲惨なことになると思う。
その辺は伝統的な3層クラサバとまんま同じノウハウが適用できる(というか必要になる)ハズ。
あとは評価してみないことには分からないけど、ウチの場合、100MB近いMDBを数十個扱う予定なので、
その結果分かったことがあれば、ここに書くよ(忘れてなければ……)。
21 :デフォルトの名無しさん2011/01/22(土) 04:43:43
sshの公開鍵をくださいと言ったら、秘密鍵と公開鍵の両方がメールで送られてきた。
BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。
BASIC認証でしか運用ができないので、Gitではなく、hgwebがあるMercurialを採用することにした。
35 :デフォルトの名無しさん2011/01/26(水) 13:40:40
hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
って、これも知っているよね?
もう1つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。
って、これも知っているよね?
もう1つの拡張の方も横取りしている。
パフォーマンスを出すためか、ディレクトリ周りはCで実装されていて、
そこがANSI APIになっている。
43 :デフォルトの名無しさん2011/01/26(水) 15:19:30
>>40
> >>35
> >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
> >って、これも知っているよね?
>
> bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
> 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
> という制限もない。
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5
何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する
が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、
ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。
別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、
日々の利用における “体感” に非常に影響を及ぼします。
訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを
低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。
> >>35
> >hgで、ファイルを細かく分けているのは同じファイルシステムでのcloneはハードリンクで、
> >って、これも知っているよね?
>
> bzrの場合は、ハードリンク機能によらない shared repository と stacked branch を
> 用意してて、同じファイルシステムで clone した後に push / pull したら共有できない
> という制限もない。
http://foozy.bitbucket.org/hgbook-ja/d6ca1334a19d/hgbookch4.html#x27-790004.5
何人かの構成管理ツールの開発者により、この方法 完全にリポジトリ固有のものとしてファイルを複製する
が ディスク使用量削減にそれほど効果的でないとの指摘を受けています。それは事実ではありますが、
ディスク容量の 確保は安価であり、 OS への複製要求を遅延することにより高い性能を得ることができます。
別な仕組みを用いる場合、性能が低下しソフトウェアの複雑さが増しますので、
日々の利用における “体感” に非常に影響を及ぼします。
訳注: つまり、 Mercurial でのハードリンクの使用は、複製を行うことによるディスクヘッドのシークを
低減するのが主眼で、ディスク使用量の低減が主眼ではな い、ということです。
46 :デフォルトの名無しさん2011/01/26(水) 23:34:10
誤解を恐れずに言えば、Gitにはブランチは存在しない
旧来のブランチの機能を果す何物かがあるだけ
旧来のブランチの機能を果す何物かがあるだけ
50 :デフォルトの名無しさん2011/01/27(木) 00:43:20
>>48
bzrはよく分かんないんだけど、
gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、
内部的には「ブランチを作る」という機能は無いと言っていい。
ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので
「ブランチを作る」というコマンドは存在する(エイリアスを作るだけのコマンド)
bzrはよく分かんないんだけど、
gitは>>46の通りで、SHA1ハッシュに対するエイリアスをブランチと呼んでいるだけで、
内部的には「ブランチを作る」という機能は無いと言っていい。
ただUIとしては「ブランチ」と特化した表現をしたほうが分かりやすいので
「ブランチを作る」というコマンドは存在する(エイリアスを作るだけのコマンド)
52 :デフォルトの名無しさん2011/01/27(木) 00:54:56
>>50
馬鹿なの?
ブランチの意味知らないんなら喋らないほうがいいよwww
馬鹿なの?
ブランチの意味知らないんなら喋らないほうがいいよwww
54 :デフォルトの名無しさん2011/01/27(木) 02:27:26
>>52
は?
は?
47 :デフォルトの名無しさん2011/01/26(水) 23:54:13
mercurialの設計で一番の間違いはブランチを名前で管理できると思ったところだと思う。
57 :デフォルトの名無しさん2011/01/27(木) 07:44:04
>>47
Mercurialの「名前付きブランチ」は「おまけ」
リポジトリの分離と名無しブランチでも運用可能
cvsのブランチのように消さないことを前提としている
名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た
「名前付きブランチ」と「リビジョン番号」はgitには無い
Mercurialの「名前付きブランチ」は「おまけ」
リポジトリの分離と名無しブランチでも運用可能
cvsのブランチのように消さないことを前提としている
名前付きブランチを乱発すると収集が付かなくなるからcloseする機能が後から出来た
「名前付きブランチ」と「リビジョン番号」はgitには無い
48 :methane2011/01/27(木) 00:12:55
え、じゃぁ
http://progit.org/book/ja/ch3-2.html
ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの?
まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo
http://progit.org/book/ja/ch3-2.html
ここでいう 'master' ブランチ とかいうのは名前付きブランチじゃないの?
まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
なるのが bzr-colo
58 :デフォルトの名無しさん2011/01/27(木) 07:46:13
>>48
> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo
用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか
> まぁ用語とかはどうでもよくて、 git checkout hoge 相当の事ができるように
> なるのが bzr-colo
用語はどうでもよいから、bzrは意味不明な用語を乱発しているのか
60 :methane2011/01/27(木) 07:58:51
>>58
いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。
で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、
この「コミットに対する名前による参照」って git はなんて定義しているの?
「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、
hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから
hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。
いちいち突っかかるなぁ。。。
僕が git が定義している用語を知らないし興味もないってだけだよ。
gitはgithubクライアントにしか使ってないから。
bzr ではきちんと用語を定義して使い分けてるよ。
で、git で refs 以下で「コミットに対する名前による参照」を提供しているけど、
この「コミットに対する名前による参照」って git はなんて定義しているの?
「ローカルブランチ」だとブランチが存在する場所が焦点になってしまって、
hgの無名ブランチと違って「名前で参照されている」という点に焦点を当てたかったから
hgの用語を拝借して「名前付きブランチ」と呼んだんだけど。
61 :デフォルトの名無しさん2011/01/27(木) 08:04:16
>>60
ローカルブランチ、リモートブランチを勉強してから出直してきな
ローカルブランチ、リモートブランチを勉強してから出直してきな
63 :デフォルトの名無しさん2011/01/27(木) 08:09:19
>>60
> 僕が git が定義している用語を知らないし興味もないってだけだよ。
bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか
> 僕が git が定義している用語を知らないし興味もないってだけだよ。
bzr開発者はgitに興味が無いから、bzrは使い勝手の悪い誰得アプリになってしまったのか
64 :methane2011/01/27(木) 08:12:07
>>61
gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。
どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。
gitも一応githubクライアントとして少しは使ってるから、
ローカルブランチとリモートブランチは使ってるよ。
どちらもコミットのハッシュ値ではなくて名前で参照できるという点では、
hgでいう「名前付きブランチ」だね。
もちろん完全に同じものとは言ってないよ。
65 :methane2011/01/27(木) 08:13:34
>>63
本当にそうなら bzr-colo なんて存在しないよ。
本当にそうなら bzr-colo なんて存在しないよ。
49 :デフォルトの名無しさん2011/01/27(木) 00:40:14
突然だけど、Meld と Diffuse ってどっちが使いやすい?
プラットホームは Linux で。ほかにも何かおすすめがあれば。
プラットホームは Linux で。ほかにも何かおすすめがあれば。
53 :デフォルトの名無しさん2011/01/27(木) 01:10:01
極端な例だけど下記のような分岐をした場合、各VCSはどのようにbranchを管理するでしょうか?
_______________branch1
_×_×_×_×_×_×_×_branch2
×_×_×_×_×_×_×__branch3
_×_×_×_×_×_×_×_branch4
×_×_×_×_×_×_×__branch5
_______________branch1
_×_×_×_×_×_×_×_branch2
×_×_×_×_×_×_×__branch3
_×_×_×_×_×_×_×_branch4
×_×_×_×_×_×_×__branch5
55 :デフォルトの名無しさん2011/01/27(木) 04:46:40
MercurialやGitのようなブランチの操作をするのに、bzr-coloが必要となる時点でBazaarは使いづらい。
「ブランチ」に対するアプローチが、
・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用
と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。
「ブランチ」に対するアプローチが、
・ディレクトリ名を指定
・共有リポジトリ作成後、その下にあるディレクトリ名を指定
・bzr-coloを利用
と3種類もある。
GitやMercurialはシンプルなコンセプトで実装が見えない所が、SVNに似ているので見えてしまうのがBazaarという印象が拭えない。
77 :デフォルトの名無しさん2011/01/27(木) 10:23:16
なんで普通に読めばbzrの不便な点が書いてあるだけなのに、それを個人に対する批判と捉えちゃうんだろう
79 :デフォルトの名無しさん2011/01/27(木) 11:01:41
>>77
bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、
誰も理解できないことを書いているのだから、批判と捉えても仕方がない
bzr特有の概念の「ブランチ」をあたかも普遍的な概念としていて、
誰も理解できないことを書いているのだから、批判と捉えても仕方がない
81 :デフォルトの名無しさん2011/01/27(木) 12:03:18
>56
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事?
変わった使い方だな。
> 作業を思い出すのが楽とか、ブランチ間の差分をバージョン管理システムの機能を
> 使わなくてもGUIのDiffツールの機能でツリーごと比較できるとか)
svnでrepo/projectname/trunkをチェックアウトするのではなく、
repo/projectnameをチェックアウトしてたって事?
変わった使い方だな。
82 :methane2011/01/27(木) 12:19:23
>>81
project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない?
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
をそれぞれ並列にチェックアウトして作業したい事ってない?
僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
というかこれもう完全にbzrの話じゃないよね。
hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
84 :デフォルトの名無しさん2011/01/27(木) 12:41:23
>>82
> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない?
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは?
> project 全体ではなくても、 trunk と branches/feature-a と branches/bugfix-foo
> をそれぞれ並列にチェックアウトして作業したい事ってない?
> 僕はメンテナンス中のブランチは大抵全部作業ツリー置いてる。
hgは同じファイルシステムだとリポジトリはハードリンクだからコストがかからなし、
gitもhgもcheckoutで切り替えればいいだけ
わざわざ全部チェックアウトするメリットは?
86 :デフォルトの名無しさん2011/01/27(木) 12:50:52
>>81
> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事?
> 変わった使い方だな。
なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか
> svnでrepo/projectname/trunkをチェックアウトするのではなく、
> repo/projectnameをチェックアウトしてたって事?
> 変わった使い方だな。
なるほど、bzrは"svn switch"も簡単にできないから全部チェックアウトする必要があるのか
87 :methane2011/01/27(木) 12:53:10
>>84
だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。
別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。
というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。
だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
持っておきたい場合があるんだって。
コミットしない変更とか、バージョン管理下に無いテストデータとか、
色々なゴミファイルが作業ツリー配下にできるから。
別に git stash; git checkout; とかでも良いんだけど、ファイルシステム上に
合った方がテキストエディタで開くにもgrepするにも何かと便利だったりするんだよ。
というかこれもう完全にバージョン管理ツールの話じゃなくて個人の
作業スタイルの話だからやめようぜ。
89 :methane2011/01/27(木) 12:55:07
>>86
bzr switch そのものズバリのコマンドがある。
bzr switch そのものズバリのコマンドがある。
90 :デフォルトの名無しさん2011/01/27(木) 12:59:49
>>87
> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。
分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか?
> だから、それぞれのブランチの作業ツリーをいちいち切り替えないで並列で
> 持っておきたい場合があるんだって。
> コミットしない変更とか、バージョン管理下に無いテストデータとか、
> 色々なゴミファイルが作業ツリー配下にできるから。
分散型で「コミットしない変更とか、バージョン管理下に無いテストデータとか」が
発生すること自体が理解できないのだが
MercurialのMQや"git merge --squash"のような機能が無いってことなのか?
91 :methane2011/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が使いにくくないと何か困ることがあるんだろうか?
違う違う、
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が使いにくくないと何か困ることがあるんだろうか?
93 :デフォルトの名無しさん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にも輸出されているそうだし。
> >>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 :methane2011/01/27(木) 13:49:43
>>93
うん、だから、
> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。
って言ってる。
作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。
ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。
bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。
うん、だから、
> もちろんそういったデータを管理するためのプラグインもある(pipeline)
> んだけど管理するよりディレクトリ分けた方が楽だと思ってるから
> 分けてるだけ。
って言ってる。
作業ツリーを分けるのは僕が楽と思ってるスタイルであって、別にbzrが推奨
しているわけではないし、bzrの機能不足で仕方なくこのスタイルをとっている
わけでもない。
ディレクトリを分けるのが面倒という意見に対する反例としてディレクトリを
分けるのが楽と感じる人もいるんだよという意味で自分のスタイルを紹介した
だけで、別にこれがbzrのスタイルではない。
bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
どのスタイルも推奨していない。
が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
可能性が高い。
99 :デフォルトの名無しさん2011/01/27(木) 16:39:14
>>94
> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。
Bazaarの言う自由度の高さとGitのこれとは何が違うの?
Pro Git 5.1 Git での分散作業 分散作業の流れ
http://progit.org/book/ja/ch5-1.html
> bzrはどんなワークフローにも対応できる柔軟性をうたっていて、現時点では
> どのスタイルも推奨していない。
> が、特にsvnではなくhgやgitのユーザー層には使いにくく感じる人が多いので、
> bzr-colo のような機能が将来的にはローカルで使うときのデフォルトになる
> 可能性が高い。
Bazaarの言う自由度の高さとGitのこれとは何が違うの?
Pro Git 5.1 Git での分散作業 分散作業の流れ
http://progit.org/book/ja/ch5-1.html
101 :methane2011/01/27(木) 16:49:44
>>99
svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。
会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。
今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。
svnと同じく checkout, update, commit でリモートと同期がとれるのが
git の中央集権よりも svn チックな使い方かな。
会社で導入したとき、svn に慣れた人には branch, pull, merge, commit, push
の一連の操作が面倒らしく、特に非プログラマには最初はすごい不評だった。
今では基本的に checkout を推奨して、bzrを使いこなしたい人だけ
ローカルにブランチ作るということにしてる。
102 :デフォルトの名無しさん2011/01/27(木) 16:53:42
>>101
それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね
それって、Subversionに慣れている人はSubversionで、
Gitに慣れている人はgit-svnのGitで、を使えば出来ることだよね
103 :デフォルトの名無しさん2011/01/27(木) 17:04:14
>>102
それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。
それだとSubversionとgitの両方の環境を維持しなきゃいけないじゃない。
101の方法だとbzrだけに統一できて管理がシンプルになる。
業務でやるなら管理のシンプルさはけっこう重要だと思うがな。
104 :デフォルトの名無しさん2011/01/27(木) 17:15:15
>>103
Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの?
Eclipse, Netbeans, Visual Studio, Trac, Redmine, Hudson
これら全てでBazaarはSubversionと遜色無く動くの?
107 :methane2011/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
で問題なく運用できてる。
あまり普通の会社じゃないからどれだけ役に立つか判らないけど、
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
で問題なく運用できてる。
83 :デフォルトの名無しさん2011/01/27(木) 12:24:13
>82
> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
いや、あんたがsvn, bzrの特徴として言い出したんだが。
> hgやgitだってローカルでcloneしたら作業ツリーたくさん持てるし。
いや、あんたがsvn, bzrの特徴として言い出したんだが。
88 :デフォルトの名無しさん2011/01/27(木) 12:54:05
Mercurialは、BazaarやGitとはちょっと違う。ブランチもまとめてclone/push/pullになる。
92 :デフォルトの名無しさん2011/01/27(木) 13:26:28
> bzrが使いにくくないと何か困ることがあるんだろうか?
Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。
Bazaarが使いづらいと、指摘している人が多いだけ。
このスレだと、比較分析されて当然。
95 :デフォルトの名無しさん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を使っている人いるの?
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を使っている人いるの?
100 :methane2011/01/27(木) 16:45:30
>>96
branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。
例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる
ことがあるけど、それを防止するのが append-revisions-only だから。
append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes
bzr-colo 使わない場合は、bzr checkout http://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 http://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は常用してないので嘘ついてるかも。後でやってみる。
branch, merge, push で運用したいなら、 append-revisions-only は設定しちゃだめ。
例えば github のグラフとか見ると、 push したら一番上のラインがゴソっと入れ替わる
ことがあるけど、それを防止するのが append-revisions-only だから。
append-revisions-only を使って運用したら、履歴がこういう風に、ほかのブランチのマージだけになる。
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes
bzr-colo 使わない場合は、bzr checkout http://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 http://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は常用してないので嘘ついてるかも。後でやってみる。
111 :methane2011/01/27(木) 19:45:00
>>109
append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100
append_revisions_only = False にするか、
trunk をチェックアウトしてそこから merge する。
詳しくは >>100
116 :デフォルトの名無しさん2011/01/28(金) 12:41:08
>>111
リビジョン番号が変化するか、不便を強いられるかの2択か。
リビジョン番号が変化するか、不便を強いられるかの2択か。
105 :1032011/01/27(木) 18:17:04
知らんよ。
動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。
でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?
動かないといけない職場なら、それを前提に検討すりゃいい。
それでbzrが候補から落ちるならそれはそれ。
でもそういう状況にないそれが必要ない職場ならbzrでいいし、実際
methaneさんとこはそういう検討の末にbzr選んだだけでしょ?
106 :デフォルトの名無しさん2011/01/27(木) 18:51:20
じゃあ、プロジェクト管理は何でやっているの?
もしかしてExcel?
だから日本語ファイル名が必要なの?
append-revisions-onlyを使わないとリビジョン番号が変わるんだよね?
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの?
make distでリビジョン番号を埋め込んだりするよね?
これもリビジョン番号変わっちゃうよね?
もしかしてExcel?
だから日本語ファイル名が必要なの?
append-revisions-onlyを使わないとリビジョン番号が変わるんだよね?
チケット駆動の開発をしていて、どのリビジョンで修正しました、ってのは、
どう指定すれば良いの?
make distでリビジョン番号を埋め込んだりするよね?
これもリビジョン番号変わっちゃうよね?
109 :962011/01/27(木) 19:38:11
オレの問題は解決しないの?
110 :デフォルトの名無しさん2011/01/27(木) 19:41:58
>>109
これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない
これまでのレスを見ての通り、日本でBazaarを分散型として使っている人はいない
118 :デフォルトの名無しさん2011/01/28(金) 14:06:25
それは、ChangeLogを書き換えてコミットしたら、もうリポジトリはChangeLogとは
違うバージョンになってるってことと比べて、どの程度の不便さなん?
違うバージョンになってるってことと比べて、どの程度の不便さなん?
120 :デフォルトの名無しさん2011/01/28(金) 18:32:49
>>118
ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
http://svnlogbrowser.org/demo/
ChangeLogって、CVSのログから自動生成するものだと思っていたが、手書きするのか
Subversion以降見かけたことが無いからぐぐってみたら、こんなの見つけた
http://svnlogbrowser.org/demo/
119 :デフォルトの名無しさん2011/01/28(金) 14:11:57
ChangeLogはCVSのバッドノウハウじゃない?
リリースノートは別管理でしょ?
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが
リリースノートは別管理でしょ?
Bazaarにあるか知らないけど$Rev$が意味をなさない弊害は大きいと思うが
121 :デフォルトの名無しさん2011/01/29(土) 10:55:21
>>297
これって何で美乳なの?微乳じゃいかんの?
これって何で美乳なの?微乳じゃいかんの?
123 :デフォルトの名無しさん2011/01/29(土) 11:48:47
>>121
美乳 EUCでぐぐってみよう
美乳 EUCでぐぐってみよう
124 :デフォルトの名無しさん2011/01/29(土) 11:55:48
>>121 は落ちたスレへの誤爆と思われ
次スレがあるのでそちらへどうぞ
http://hibari.2ch.net/test/read.cgi/tech/1291075205/
297 名前:デフォルトの名無しさん [sage]: 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ?
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの?
エンコーディングが明確になるだ?
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
次スレがあるのでそちらへどうぞ
http://hibari.2ch.net/test/read.cgi/tech/1291075205/
297 名前:デフォルトの名無しさん [sage]: 2010/09/10(金) 12:24:16
>>290
>>292
>>294
単なるZERO WIDTH SPACEだ?
じゃあお前らは編集者が意図した覚えも無いのに、先頭に勝手にunkoって保存されたりされなかったりする環境に何の問題も感じないの?
エンコーディングが明確になるだ?
文字化け対策の<!-- 美乳 -->かっつーの
いらねーもん無断でつけんなカス
122 :デフォルトの名無しさん2011/01/29(土) 11:18:08
なるほど。乳をバージョン管理か。そいつは思いつかなかったw。
130 :デフォルトの名無しさん2011/02/16(水) 17:08:32
Git 6/Hg 3/Bzr 1
132 :デフォルトの名無しさん2011/02/16(水) 17:20:26
>>130
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
githubが目立つからそうかもしれないけど、
hgはbitbucket/google code/codeplexと分散しているのと、
hgwebが簡単に立てられて、自前で立てている所が多いから、
オープンソースでもhgはもっと多いと思う。
hgはWindowsサポートでgitより先に行っていたので、企業内ではさらに多いと思う。
133 :デフォルトの名無しさん2011/02/16(水) 17:35:28
134 :デフォルトの名無しさん2011/02/16(水) 17:49:06
>>133
一面ではあると思うが参考になったthx。
一面ではあると思うが参考になったthx。
289 :デフォルトの名無しさん2011/02/28(月) 01:10:26.03
>>133
Debian LinuxではGitは2010/04/03まではgit-coreパッケージ、それ以降はgitパッケージです。
2008/01/10にgitパッケージ(Gitとは別物)がgnuitに改名されました。
2010/04/03にgit-coreパッケージがgitに改名され、git-coreはgitのダミーパッケージになりました。
ダミーパッケージをインストールすると自動的に本来のパッケージもインストールされます。
つまり、Debian LinuxにおけるGitのインストール数は、
2010年3月まではgit-coreのグラフ、2010年後半からはgitのグラフで表されます。
GitはすでにCVSを越え、今年中にSubversionを越えそうです。
Popularity contest statistics for bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion
http://qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1
http://packages.debian.org/changelogs/pool/main/g/gnuit/current/changelog.html#versionversion4.9.2-1
gnuit (4.9.2-1) unstable; urgency=low
> * Package name changed to gnuit.
> * Added transitional git package.
> -- Ian Beckwith <ianb@erislabs.net> Thu, 10 Jan 2008 22:04:26 +0000
http://packages.debian.org/changelogs/pool/main/g/git/current/changelog#versionversion1:1.7.0.4-2_exp0
git (1:1.7.0.4-2~exp0) experimental; urgency=low
> * debian/control, debian/rules, debian/git-core.*: change source and
> binary package name from git-core to git; keep now obsolete empty
> git-core package that depends on git for upgrade (see
> http://lists.debian.org/debian-devel/2009/09/thrd2.html#00661).
> -- Gerrit Pape <pape@smarden.org> Sat, 03 Apr 2010 15:07:19 -0500
Debian LinuxではGitは2010/04/03まではgit-coreパッケージ、それ以降はgitパッケージです。
2008/01/10にgitパッケージ(Gitとは別物)がgnuitに改名されました。
2010/04/03にgit-coreパッケージがgitに改名され、git-coreはgitのダミーパッケージになりました。
ダミーパッケージをインストールすると自動的に本来のパッケージもインストールされます。
つまり、Debian LinuxにおけるGitのインストール数は、
2010年3月まではgit-coreのグラフ、2010年後半からはgitのグラフで表されます。
GitはすでにCVSを越え、今年中にSubversionを越えそうです。
Popularity contest statistics for bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion
http://qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1
http://packages.debian.org/changelogs/pool/main/g/gnuit/current/changelog.html#versionversion4.9.2-1
gnuit (4.9.2-1) unstable; urgency=low
> * Package name changed to gnuit.
> * Added transitional git package.
> -- Ian Beckwith <ianb@erislabs.net> Thu, 10 Jan 2008 22:04:26 +0000
http://packages.debian.org/changelogs/pool/main/g/git/current/changelog#versionversion1:1.7.0.4-2_exp0
git (1:1.7.0.4-2~exp0) experimental; urgency=low
> * debian/control, debian/rules, debian/git-core.*: change source and
> binary package name from git-core to git; keep now obsolete empty
> git-core package that depends on git for upgrade (see
> http://lists.debian.org/debian-devel/2009/09/thrd2.html#00661).
> -- Gerrit Pape <pape@smarden.org> Sat, 03 Apr 2010 15:07:19 -0500
135 :デフォルトの名無しさん2011/02/16(水) 22:40:17
大事なのは、
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
どのVCSを使うかではなく、
VCSを使って何を作るかである、
とジョン・F・ケネディーも言っていたお。
136 :デフォルトの名無しさん2011/02/23(水) 13:50:37.67
最近、
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
思ったけどWindowsのデフォルトロケールをUTF-8に出来ないんだろうかね・・・
Linuxは、UTF-8にできるし、MacはUTF-8
Windowsさえ変えれれば幸せになれるんだけどなぁ・・・(正規化はおいとくとして)
いずれにせよ、GiもHgもバイナリ列でファイル名を扱うってポリシーなんだから
そのバイナリ列を作る部分にフックを置いて変換できるようにしといてくれればいいんだよぉ・・・
137 :デフォルトの名無しさん2011/02/23(水) 14:50:33.54
>>136
文字コードスレによれば、WindowsでDBCSが2バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
文字コードスレによれば、WindowsでDBCSが2バイトまでと決まっているから無理だそうだ
Mercurialでは関数のよこどりで実現している。あまり美しくないけど
開発者の問題意識はあるという所まで来ているので、大きい声をあげれば
フックみたいなのも実現できるかもしれない
138 :デフォルトの名無しさん2011/02/23(水) 15:47:16.08
>>137
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が?前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
Windows8以降でいいのでその辺り何とかして欲しいです・・・
いい加減、UTF-8を扱えないシステムって旧世代ってイメージが・・・
Mercurialの開発者に問題意識が?前は問題はないんだ、
という姿勢だったところからすれば勉強したのかね。自分の視野の狭さっぷりを。
139 :デフォルトの名無しさん2011/02/23(水) 15:54:28.95
Windows は NT のころから Unicode (UCS-2) 対応してて、LinuxやMacよりも
対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
対応全然早かったんだけどな。
互換性のためにMBCSのAPIを残しているだけなんだから、Windowsの視点で言えば
10年以上前から用意しているUnicode API使わないで Windows 95 互換API使ってる
アプリの方が旧世代という事になる。
141 :デフォルトの名無しさん2011/02/23(水) 16:04:56.51
2byte用意しときゃ足りるだろ、というSingleByte圏の連中の発想が罪深い・・・・
142 :デフォルトの名無しさん2011/02/23(水) 16:17:51.15
>>141
DBCS=MBCSだからCP932用
UTF-16とは関係ない
DBCS=MBCSだからCP932用
UTF-16とは関係ない
144 :デフォルトの名無しさん2011/02/23(水) 17:29:00.69
>>142
あー、ごめん、Unicode策定してた連中に言ったつもりだった。
あー、ごめん、Unicode策定してた連中に言ったつもりだった。
147 :デフォルトの名無しさん2011/02/23(水) 23:20:04.23
>>141
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
Windows対応のクロスプラットフォームアプリを作る場合は、内部の
文字コードをUTF-8に統一するケースとUTF-16に統一するケースがある。
gtkは前者だし、Python、Java、CLI、wxWidgets、Qt は後者。
156 :デフォルトの名無しさん2011/02/24(木) 23:49:54.49
>>153
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
>>147 も書いてるように、現役バリバリ。
UCS4にしたら、容量はほとんど倍になるのに、利点はサロゲートペアの
処理が不要になることくらいで、1文字が1コードポイントになるわけじゃない。
162 :デフォルトの名無しさん2011/02/24(木) 23:57:10.63
>>156
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
現役なんじゃなくて歴史を引き摺ってるだけでしょ
日本人以外にとっては UTF-16 が救世主に見えた時があったからね
146 :デフォルトの名無しさん2011/02/23(水) 19:37:32.05
Windows対応アプリを作る場合は、APIコールの度に毎回UTF-8→UTF-16変換してW版APIを呼ぶのが正道なんだけど
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
DBCSで苦労してない言語圏の連中はわかっちゃいないからな。
Windows専用アプリならアプリ内部まで全部UTF-16で統一するのが普通。
148 :1472011/02/23(水) 23:21:23.77
UTF-16というか、UTF-8以外のUnicode表現。UTF-16決め打ちじゃなくて
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
処理系の wchar_t に合わせる場合や、 Python のように UTF-16 と
UTF-32 を選べる場合もある。
149 :デフォルトの名無しさん2011/02/24(木) 23:28:17.70
文字としては、さすがにUCS-4で足りるだろうから
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
内部表現はUTF-32、外部表現はUTF-8ってのを標準にしてくれたら
スッキリするんだけどなぁ。
150 :デフォルトの名無しさん2011/02/24(木) 23:34:29.78
>>149
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
UTF-32だとメモリ使用量が上がる割には、別に1文字が1コードポイントに
なるわけでもないし、あんまり嬉しくない。
CJK以外はUTF-8が、CJKも含めるとUTF-16がベストバランス。
151 :デフォルトの名無しさん2011/02/24(木) 23:36:42.45
>>150
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
UTF-8 は1コードポイントが何バイトになるか不定だから、内部コーディングと
しては UTF-16 がベストバランス。
152 :デフォルトの名無しさん2011/02/24(木) 23:42:06.92
Javaって今は内部UTF-16でインターフェースは好きにできる感じじゃなかったっけ。
WindowsはUTF-16固定?
WindowsはUTF-16固定?
153 :デフォルトの名無しさん2011/02/24(木) 23:46:12.23
普通は内部文字コードは UCS4 じゃないの
UTF-16 は負の遺産という認識だったけど
UTF-16 は負の遺産という認識だったけど
154 :デフォルトの名無しさん2011/02/24(木) 23:49:15.38
UTF-16はサロゲートペアが気持ち悪いのでちょっと・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
Javaはchar型が16bitだからプリミティブ型でUnicodeの文字全部は扱えないし・・・
無理矢理過ぎるんだよ・・・ASCII圏の人間に理解してもらえる訳ないじゃないか・・・
155 :デフォルトの名無しさん2011/02/24(木) 23:49:40.00
つうか、後顧の憂いを残さない為には、内外共にUTF-8にしておくのがベストなんじゃ?
157 :デフォルトの名無しさん2011/02/24(木) 23:52:04.46
>>155
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
UTF-8にしたら結合文字やサロゲートペアの処理どころか
マルチバイトの処理まで必要になる。
内部コードをUTF-8の方針をとっているフレームワークも
あるけど少数派。
158 :デフォルトの名無しさん2011/02/24(木) 23:52:24.00
>>155
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
内をUTF-8にしたら処理が重くなると思うよ。
内部形式としては、固定長が幸せになれると思う。
159 :デフォルトの名無しさん2011/02/24(木) 23:52:55.00
内部コードを何にするかが、バージョン管理システムにどう影響するんだ?
いい加減スレ違いだからUnicodeスレに行け。
いい加減スレ違いだからUnicodeスレに行け。
160 :デフォルトの名無しさん2011/02/24(木) 23:53:13.04
ってか、こんな問題の関わりたくないからファイル名はバイナリだ、とかいう割り切りになってんだろうね。
161 :デフォルトの名無しさん2011/02/24(木) 23:54:28.69
>>160
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
内部コードを何にするかとファイル名をどう扱うかは全く関係ないが。。。
163 :デフォルトの名無しさん2011/02/25(金) 00:13:29.48
プログラム用のバージョン管理システムが扱う文字の範囲なんて殆ど ascii の範疇なんだから、
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
UTF-8 でも重くなりようが無い。UTF-16 はハナから無いでしょ。
164 :デフォルトの名無しさん2011/02/25(金) 00:16:13.76
保存用はそりゃUTF-8だろ。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
今話してるのは、バージョン管理システムに限らず一般的なアプリケーションの
内部エンコーディングの話。つまりスレ違い。
243 :デフォルトの名無しさん2011/02/26(土) 03:25:05.29
>>240
>バージョン管理システム内だけで使う文字コードじゃないの?
つ >>164
>バージョン管理システム内だけで使う文字コードじゃないの?
つ >>164
247 :デフォルトの名無しさん2011/02/26(土) 03:29:23.71
>>243
あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。
あーなるほどね。
そう言う話なら、ぶっちゃけどうでも良いや。
248 :デフォルトの名無しさん2011/02/26(土) 03:30:07.68
>>247
そう、ぶっちゃけどうでも良いのです。
そう、ぶっちゃけどうでも良いのです。
165 :デフォルトの名無しさん2011/02/25(金) 00:26:42.61
元々はWindowsでファイル名が化ける云々…というのが発端で、
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
どうなれば最適解なんだろね、という話だから、それほど脱線でもないでしょ。
OS依存の話すんな、と言われればそれまでかも知れんが。
166 :デフォルトの名無しさん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にエンコードしてシステムコール呼ぶのと一緒。
Windows に限定した話題なら、Unicode APIを使え、でFAだろ。
内部コーディングにUTF-8を使おうがUTF-32を使おうが、Unicode APIを
呼ぶときにUTF-16に変換すれば良い。
Javaが内部ではUTF-16でファイル名を扱ってても、Linuxでファイル名を
指定するときはUTF-8にエンコードしてシステムコール呼ぶのと一緒。
167 :デフォルトの名無しさん2011/02/25(金) 07:25:35.98
>>166
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
Windows以外ではファイル名に'\0'が入るのがアウトだから変換が必要。
JavaのShift_JIS、ms932のカオスをVCSがやる必要があるのか。
168 :デフォルトの名無しさん2011/02/25(金) 07:56:03.02
>>167
内部エンコーディングの意味わかってる?
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
内部エンコーディングの意味わかってる?
API呼び出すときには、内部エンコーディングをそのプラットフォームの
APIに合わせるんだよ。
QtだってJavaだって、内部ではUTF-16を使って、Linuxでシステムコールを
呼ぶときにはバイト列に変換して呼び出してる。
169 :デフォルトの名無しさん2011/02/25(金) 08:05:16.70
>>168
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね?
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね?
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね?
分かっているよ。
VCSはファイルのバージョン管理をするソフトだよね?
git/mecurialはLinux生まれなんだから、内部をUnicodeにする必要は無いよね?
そんなことをしたらLatin-1の人にとってはパフォーマンス劣化して使いづらいものになるよね?
170 :デフォルトの名無しさん2011/02/25(金) 08:11:27.04
>>169
そこがパフォーマンス上ボトルネックになるとでも思っているのか…
そこがパフォーマンス上ボトルネックになるとでも思っているのか…
171 :デフォルトの名無しさん2011/02/25(金) 08:18:17.40
>>170
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ?
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの?
Mercurialのコンソールのutf-8の日本語メッセージ(usageなど)の対応でも、
パフォーマンス劣化したって文句が上がってるんだよ?
Bazaarはいつになったらコンソールの日本語メッセージが出るようになるの?
172 :デフォルトの名無しさん2011/02/25(金) 08:33:17.66
>>171
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
i18n でパフォーマンスが劣化するとしたら、コールドスタート時に
メッセージカタログがディスクキャッシュに載ってない場合くらい。
メッセージのルックアップを繰り返しも少しオーバーヘッドになるから
繰り返して呼ばないようにする必要があるけど、Unicodeからlocale
への変換はさらに低コスト。
実使用には全く問題ないオーバーヘッド。そんなの気にする奴は
ベンチマーク厨だけ。
173 :デフォルトの名無しさん2011/02/25(金) 08:39:29.22
>>172
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは2倍になるよね?
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
32ビットOSでは動かなくなるよ?
だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは2倍になるよね?
Linuxカーネルのようにギガを超えているものだと、statusチェックだけでも、
32ビットOSでは動かなくなるよ?
174 :デフォルトの名無しさん2011/02/25(金) 08:45:24.40
>>173
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの?
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは2倍になるよね?
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん?
>だから端末表示では古典的な全角半角処理でだめだからutf-8では特別な処理が必要なの
意味がわかんない。今までの内部エンコーディングの話とどう関係するの?
>gitでファイル名の内部形式をバイト列からUTF-16にしたらメモリは2倍になるよね?
ファイル名のところだけな。
gitのメモリ消費はファイル名が大きな部分を占めてるん?
175 :デフォルトの名無しさん2011/02/25(金) 08:50:59.41
>>174
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
checkoutしたときのロケールとコミットするときのロケールが違うことはありえる
git/hg statusコマンドを叩く度に内部でファイル名をUnicodeに変換するとしたら使いものにならない
176 :デフォルトの名無しさん2011/02/25(金) 09:03:22.14
>>175
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
なるほど、バイナリ透過派だったのね。話が噛み合わないわけだ。
内部エンコーディングが UTF-8 vs UTF-16 の話からいつの間に話題が
変わってたんだろ。
バイト透過はLinuxの世界に引きこもる場合はロケール無視できて幸せだけど、
ファイルシステムがUnicodeなMacやWindowsと共同作業するのにはあまり
向かない。
俺は別に非ASCIIファイル名を使わないから気にしないけど。
177 :デフォルトの名無しさん2011/02/25(金) 09:39:03.80
>>176
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
Merurialはファイル名以外は内部UTF-8
Gitはログもバイト列でエンコード情報を付加している
どっちも正しい多言語化
178 :デフォルトの名無しさん2011/02/25(金) 10:03:21.47
>>177
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
あー、内部エンコーディングの話を無理やりbzrをディスる方向に
持って行きたかったのね。はいはい。
ファイル名に関しては、「たったひとつの正しい多言語対応」なんてものは存在しない。
ファイル名の扱いがOS毎に異なるんだから。
179 :デフォルトの名無しさん2011/02/25(金) 10:23:05.55
>>178
うん、bzrの設計はおかしい。
2005年だとJavaの文字2バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
うん、bzrの設計はおかしい。
2005年だとJavaの文字2バイトのおかしさは認識されていたはずだし、
Linuxのutf-8ロケールも実用的になっていた。
Debian/UbuntuがLinux上のファイルシステムがエンコードを持っていないということを
知らなかったとしか思えない。
180 :デフォルトの名無しさん2011/02/25(金) 10:35:36.51
>>179
> 2005年だとJavaの文字2バイトのおかしさは認識されていたはずだし、
> 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 の多言語対応について判ってると思うぞ。
> 2005年だとJavaの文字2バイトのおかしさは認識されていたはずだし、
> 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 の多言語対応について判ってると思うぞ。
182 :デフォルトの名無しさん2011/02/25(金) 10:38:27.52
>>180
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
>意味不明。
>別にEUCでもバイト透過にしたっていいじゃない。
本当は意味が分かってるんじゃないの?
本当は EUC にして良いとは思ってないんじゃないの?
187 :1802011/02/25(金) 10:50:37.47
>>182
Unicodeに統一したいの?したくないの?
まったく意味が判らないよ。
Unicodeに統一したいの?したくないの?
まったく意味が判らないよ。
192 :methane2011/02/25(金) 12:40:06.97
>>191
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
一応言っておくけど、bzrがNFCで正規化するのはファイル名だけで、
コミッターやコミットログには示申を書いても神になったりしないよ。
hg, git と同じレベルで問題ない。
ファイル名をUnicodeで扱うのが正しいのかどうかは、>>178の言うとおり
正解はない。どのポリシーを選択するかだけ。
205 :デフォルトの名無しさん2011/02/25(金) 18:45:30.52
>>180
> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが?
> Linuxでutf-8ロケールが実用になっていることがファイル名をバイト透過に
> するかどうかとは無関係。別にEUCでもバイト透過にしたっていいじゃない。
ということで、Git/Mercurialは、Linuxではバイト透過で、
cygwinでは、LANG=ja_JP.EUC-JPでEUC-JPファイル名を使えますが?
210 :デフォルトの名無しさん2011/02/26(土) 00:32:46.22
>>187
Unicode と言ったら、今は UTF-8 か UTF-32
Unicode と言ったら、今は UTF-8 か UTF-32
211 :デフォルトの名無しさん2011/02/26(土) 00:39:59.28
>>210
お前の頭の中だけな。
お前の頭の中だけな。
244 :デフォルトの名無しさん2011/02/26(土) 03:25:40.70
>>242
この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。
この議論はそもそも >>210 から始まったんだが。。。
UTF-16 を採用することがあるとすれば、それは効率と扱いやすさのバランス。
246 :デフォルトの名無しさん2011/02/26(土) 03:28:47.22
>>244
効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙
効率も悪いし、サロゲートペアが必須で扱い辛い文字コード乙
249 :デフォルトの名無しさん2011/02/26(土) 03:30:08.18
つまり、ファイル名をunicodeで扱うかバイト列で扱うかという話に、
何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。
何故か今までWindows APIがUTF-16という点でしか登場する機会のなかった
UTF-16をdisり始めた >>210 が現れて、スルーできずにUTF-16の利点を
説明しだす奴が現れて、さらに何故かUTF-16がUTF-8より優れているという
議論をしていると勘違いしてる奴が現れた。
250 :デフォルトの名無しさん2011/02/26(土) 03:32:09.41
>>249
そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。
そして今、君が颯爽と現れてこれからこのスレを有意義な話題で盛り上げてくれる訳だ。
251 :デフォルトの名無しさん2011/02/26(土) 03:32:49.71
>>246
効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8
効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。
効率: UTF-8 < UTF-16 << UTF-32
処理しやすさ: UTF-32 < UTF-16 << UTF-8
効率と処理しやすさのどっちか片方しか必要ない場合は君の言うとおり。
どっちも必要な場合はバランスが良いフォーマット。
253 :デフォルトの名無しさん2011/02/26(土) 03:39:34.62
>>251
結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ
結局、固定長を前提に出来ない時点で UTF-16 に処理し易さなんて無いよ
UTF-8 が ascii の範囲では固定長だから処理がし易いと言ってるのと同じ
181 :1802011/02/25(金) 10:37:41.52
>UTF-16 は Unicode のほとんどの文字集合を表現可能で、
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の(まだ文字が割り当てられていないコードを含む)ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
>UTF-16 で表現できない範囲に文字集合が拡張される事は永遠にないだろう。
の部分の日本語がおかしかった。
Unicode の(まだ文字が割り当てられていないコードを含む)ほとんどのコードを
表現可能で、UTF-16で表現できないコードに対して文字が割り当てられることは
永遠にないだろう。
183 :デフォルトの名無しさん2011/02/25(金) 10:38:56.90
bzrはどの分散管理よりもマルチ環境で使える
これが全て
他のは日本語環境だと使い物にならない
これが全て
他のは日本語環境だと使い物にならない
184 :デフォルトの名無しさん2011/02/25(金) 10:40:51.98
そっか。じゃあ俺は Git を使うわ。問題が起きた事無いし。
285 :デフォルトの名無しさん2011/02/27(日) 01:23:27.31
>>184
うん、いいと思うよ。俺も一人だけ作業ならそうしてる
うん、いいと思うよ。俺も一人だけ作業ならそうしてる
185 :デフォルトの名無しさん2011/02/25(金) 10:41:55.69
例えばSubversionの場合、
WindowsではUTF-16に変換してUnicode APIを呼ぶ(リポジトリ内部はUTF-8?)
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな?
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない?
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
WindowsではUTF-16に変換してUnicode APIを呼ぶ(リポジトリ内部はUTF-8?)
Unix系ではその時のロケールに変換して出力、
って感じで、プラットフォーム毎に対応してるのかな?
単に表示上の問題だけならUIで吸収できると思うんだけど、ファイル名となると
ファイルシステムが対応してないとダメじゃない?
Linuxのファイルシステムって、内部表現とかあるんだろうか。
ファイル名のバイト表現が不定になると動かなくなるアプリとか、けっこうありそうな…
186 :1802011/02/25(金) 10:49:26.64
>>185
subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
subversion に関しては yes
ファイルシステムに関しては、Linuxの場合は標準的に使われている
ファイルシステム(ext, btrfs, xfs, reiserfs)はバイト透過型。
Unicode型のHFS+を使ったりもできるけどね。
ファイル名のバイト表現が不定だと動かないのは、まさにMakefile
クロスプラットフォームではASCII文字以外使いものにならないけど、
Makefileに非ASCII文字書きたい人があまりいないから問題ない。
antとかはsvnと同じ方式だから、逆にロケールや環境が変わってるのに
バイト列が保存されてると動かない。
188 :デフォルトの名無しさん2011/02/25(金) 11:34:29.81
ファイル名なんかよりもコミットログ、特にコミットユーザ名が一番重要。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
フランス人、ドイツ人にコミットユーザ名に非ASCIIを使うな、って言えない。
git、hgは入力・出力どっちもきちんと対応している。
bzrはファイル名もロケール依存になっている不思議な設計。
189 :デフォルトの名無しさん2011/02/25(金) 11:50:50.34
>>186
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では?
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな?
なるほど。ファイルシステムはパフォーマンス出したいところだから、
内部はバイト透過にしておきたいだろうなぁ。
>>188
Subversionもファイル名ロケール依存では?
現状を考えると、フランス人ドイツ人もユーザ名はASCIIでは困るけど、
ファイル名はASCIIでいいよ、って感じなのかね。
それかどうしてもファイル名に非ASCII使いたい場合はUTF-8決めうちにしておいて、
UI側でそう見做せばいいでしょ、っていうのがLinux方面のスタンスかな?
190 :デフォルトの名無しさん2011/02/25(金) 12:20:48.99
>>188
全部大事
全部満たしてるのがbzrだけ
全部大事
全部満たしてるのがbzrだけ
191 :デフォルトの名無しさん2011/02/25(金) 12:27:11.43
>>190
日本人の人名で普通に使われている文字がbzrでは使えないよね?
日本人の人名で普通に使われている文字がbzrでは使えないよね?
194 :デフォルトの名無しさん2011/02/25(金) 13:43:27.41
そんなものを求めたら宗教戦争に巻き込まれるだけだと思うぞ
195 :デフォルトの名無しさん2011/02/25(金) 14:51:51.55
いあ、add時のプラットフォームとエンコーディングをメタ情報に持った上でファイル名自体はバイナリとして保存、
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
比較や他プラットフォームに展開するときのみコード変換、正規化。
このやり方ならUnicode決め打ちよりはずっと多くの文字を正確に扱える。
こんなめんどくさいことをしてるアプリは見たことないが。
196 :デフォルトの名無しさん2011/02/25(金) 14:54:01.19
>>195
よう、いいだしっぺ
よう、いいだしっぺ
198 :デフォルトの名無しさん2011/02/25(金) 15:17:45.41
>>195
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの?
そのアプローチだと、ひとつのファイル名に
互換性のない複数のエンコーディングが混じった場合どうすんの?
199 :デフォルトの名無しさん2011/02/25(金) 15:21:00.63
>>198
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか?
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
例えばLinuxでLANGをSJISにして「あ.txt」を追加、次はEUCにして「あ.txt」を追加、とかか?
それでも同じLinux上でチェックアウトするなら片方文字化けするだけで問題ない。
他のOSに持って行こうとすればエラーにでもすればいいと思う。
(理屈としてはWindowsでA.txtとa.txtが同時に存在できないのと同じ)
201 :デフォルトの名無しさん2011/02/25(金) 16:33:31.64
>>199
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
cygwinがそれをやっているので、git/hg本体がやる必要性が無くなった
202 :デフォルトの名無しさん2011/02/25(金) 16:38:53.66
>>201
Eclipseで使えないと困っちゃうんだよねぇ・・・
Eclipseで使えないと困っちゃうんだよねぇ・・・
203 :デフォルトの名無しさん2011/02/25(金) 16:50:04.22
>>201
それってUTF-8対応したCygwinってやつ?
てことは、WindowsでもCygwinなら化けない?
それってUTF-8対応したCygwinってやつ?
てことは、WindowsでもCygwinなら化けない?
204 :デフォルトの名無しさん2011/02/25(金) 17:15:40.44
>>203
そうだよ、EUC-JPのファイル名もチェックアウトできるよ
そうだよ、EUC-JPのファイル名もチェックアウトできるよ
206 :デフォルトの名無しさん2011/02/25(金) 19:21:43.99
>>201
NTFSがUTF-16なのにどこで保存してるんだ?
セカンドストリーム?
NTFSがUTF-16なのにどこで保存してるんだ?
セカンドストリーム?
209 :デフォルトの名無しさん2011/02/25(金) 23:34:44.37
>>207
まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑
まっとうな対応とは思うが、>>201の言ってることは何なんだ(苦笑
197 :デフォルトの名無しさん2011/02/25(金) 15:17:44.23
もうMIMEエンコードして保持しとけよ
200 :デフォルトの名無しさん2011/02/25(金) 16:29:57.73
>>197
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
Mercurialのリポジトリファイル名はそんな感じ。
だから、UTF-8だろうがコロンが入ろうが、リポジトリはFATに置ける
207 :デフォルトの名無しさん2011/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 上で見る場合は逆変換されるので普通に見える。
- 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 :デフォルトの名無しさん2011/02/25(金) 23:10:55.47
Mercurialのファイル名問題のほんとの理由は、コア開発者の中に、
非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。
非ASCIIファイル名を感情的に嫌ってるやつが居ることだから、
技術的にあれこれ言っても無意味。
348 :デフォルトの名無しさん2011/04/26(火) 09:26:52.41
>>345
つ>>208
つ>>208
212 :デフォルトの名無しさん2011/02/26(土) 00:41:32.04
Unicode が俺の頭の中にあったとは!
でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。
でも、お前さんらも使っていーよ。UTF-8 と UTF-32 ね。
213 :デフォルトの名無しさん2011/02/26(土) 00:49:19.48
>>212
WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。
WindowsでもJavaでも.NETでも頑張ってUTF-8かUTF-32使ってろ。
アホくさ。
214 :デフォルトの名無しさん2011/02/26(土) 00:50:59.24
>>213
Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ
Servlet ではもっぱら UTF-8 で入出力してるよ
過去のしがらみを引き摺ってる方がアホくさ
216 :デフォルトの名無しさん2011/02/26(土) 01:04:09.03
>>214
Servlet って Java か?
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。
っていうか、入出力って、外部エンコーディングの話してたの?
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの?
それとも内部エンコーディングっていう単語の意味がわからなかったの?
Servlet って Java か?
おもいっきり UTF-16 使ってるだろ。
クラス名だってUTF-16だぞ。文字列全部UTF-16だぞ。
っていうか、入出力って、外部エンコーディングの話してたの?
頑張ってUTF-16をdisってるみたいだけど、どこにファイルフォーマットや
ネットワーク転送時にUTF-16を使ってるバージョン管理システムがあるの?
それとも内部エンコーディングっていう単語の意味がわからなかったの?
217 :デフォルトの名無しさん2011/02/26(土) 01:07:07.26
>>216
Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ
Java の内部エンコーディングを俺が決められるなら UTF-16 なんて使わねえよ・・・
過去に遡って Java のエンコーディングを変える事が出来たとして UTF-16 を選ぶ人間は独りだけだろ
もっと足元の現実を見ようぜ
218 :デフォルトの名無しさん2011/02/26(土) 01:10:43.62
>>217
なんで?UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。
なんで?UTF-16って固定符号長だしUnicodeで定義されている文字を
全部表現できるし、どうせUTF-32にしたってメモリ使用量がほぼ倍になるのに
1文字1コードポイントにならないし、UTF-32に拘る理由なんてないでしょ。
219 :デフォルトの名無しさん2011/02/26(土) 01:15:24.95
>>218
何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。
今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・
何でって固定長の振りして実際は固定長じゃないからだよ。
プログラムで扱う文字列の殆どは数字とアルファベットだから UTF-16 にしたら
メモリ使用量が倍以上になるし、出力する際も UTF-8 が殆どなんだから、
変換するだけ処理時間の無駄。
今更、こんなどうでも良い事で抵抗しても何の意味も無いじゃん・・・
220 :デフォルトの名無しさん2011/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を
選んでいるのは、それなりにメリットがあるから。
文字の符号数が固定でなくても、符号が固定長なのは処理の楽さに影響するよ。
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 :デフォルトの名無しさん2011/02/26(土) 01:49:29.33
>>220
それは今更 UTF-16 を使う理由にはならないよね
何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?
それは今更 UTF-16 を使う理由にはならないよね
何でサロゲートペアやバイトオーダーを無視するの?
何で UTF-8 がデファクトとなっている世の中でわざわざ UTF-16 に変換するコストを無視するの?
何で CJK の文字列の中でも数字やアルファベットが多数含まれている事を無視するの?
何でそんな過去の技術に拘りたいの?
223 :デフォルトの名無しさん2011/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るべき。
サロゲートペアを考慮する必要があるケースって、文字単位で処理をしたい
場合だろうけど、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るべき。
222 :デフォルトの名無しさん2011/02/26(土) 02:01:08.43
ご家庭用パソコンにメモリ4GBとかHDD2TBとかいう時代にメモリ効率はないわ〜
文字列が可変長なんだから、文字も可変長になっててどこがいけないのか?
UTF-8マンセー!
文字列が可変長なんだから、文字も可変長になっててどこがいけないのか?
UTF-8マンセー!
226 :デフォルトの名無しさん2011/02/26(土) 02:12:39.15
>>222
俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。
http://practical-scheme.net/gauche/memo-str-j.html
俺もそう思うわ。
↓こんな感じで、内部コードに UTF-8 を使用するのは十分リーズナブル。
http://practical-scheme.net/gauche/memo-str-j.html
227 :デフォルトの名無しさん2011/02/26(土) 02:20:15.47
>>224
俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。
俺は別にUTF-16最強と言いたいわけじゃなくて、UTF-16をレガシー扱い
するのは気が早いと言いたいだけだ。
>>225
中途半端とも言えるし、バランスがいいとも言える。
>>226
内部エンコーディングにUTF-8を使うのも十分ありだね。
Python も実装の内部でUTF-8を使えるようにしようという話は開発者の
間で議論されている。
229 :デフォルトの名無しさん2011/02/26(土) 02:22:50.71
>>227
拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ
拘ってないでレガシーだって認めちゃえよ
CJK の話だって無理があり過ぎなのは薄々感づいてるんだろ
224 :デフォルトの名無しさん2011/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 に比べたらマシですよ」
「え、UTF-8 の方が良い部分がある? いやいや UTF-16 だって UTF-32 に比べたらマシですよ」
「UTF-16 は UTF-32 に比べたらここが良いんですよ!」
「え、UTF-32 の方が良い部分がある? いやいや UTF-16 だって UTF-8 に比べたらマシですよ」
238 :デフォルトの名無しさん2011/02/26(土) 03:16:53.52
>>237
>>224
ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ
>>224
ダブスタ乙
それは都合の悪い時にもっと都合の悪い方を dis って誤摩化してるだけだろ
239 :デフォルトの名無しさん2011/02/26(土) 03:18:52.01
>>238
utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。
utf-16の非効率を指摘しながらutf-32はOKという自分のほうがダブスタ
だっていう認識はないんだな。。。
242 :デフォルトの名無しさん2011/02/26(土) 03:23:17.21
>>239
俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。
UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。
俺は UTF-8 の方が効率的だという話しかしていない。
君が勝手に UTF-32 と比較して UTF-16 を擁護しようとしているだけ。
当然 UTF-8 に対しては何の反論にもなっていない。
UTF-32 を採用する事があるとすれば、それは効率ではなく別の理由。
225 :デフォルトの名無しさん2011/02/26(土) 02:07:14.76
肝心の UTF-16 は中途半端なだけで何のメリットも無くて残念
228 :デフォルトの名無しさん2011/02/26(土) 02:22:47.15
いまどき、欧米人以外でUTF-32が固定長とか思ってる奴がいるんだな。
CJKの当事者としてもうちょっと勉強しようぜ。
CJKの当事者としてもうちょっと勉強しようぜ。
230 :デフォルトの名無しさん2011/02/26(土) 02:26:01.13
>>228
『1コードポイントは固定長』という便利な表現をこのスレで学んだからな
『1コードポイントは固定長』という便利な表現をこのスレで学んだからな
231 :デフォルトの名無しさん2011/02/26(土) 02:45:02.44
とりあえずUTF-8なCygwinなら化けないようなので、
hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ? そうでもない?
IDEからCygwinのコマンド使ってもらえばオールオッケー?
hgやGitをWindowsで使いたい人はCygwin使おうね、でFAということは分かった。
よく分からないけど、どうせIDEから使うんでしょ? そうでもない?
IDEからCygwinのコマンド使ってもらえばオールオッケー?
281 :デフォルトの名無しさん2011/02/26(土) 19:49:35.74
>>231
IDEを使うなら、utf-8ロケールのLinuxデスクトップで、
EclipseならGit、NetbeansならMercurialを使うことでオールオッケー
IDEを使うなら、utf-8ロケールのLinuxデスクトップで、
EclipseならGit、NetbeansならMercurialを使うことでオールオッケー
233 :デフォルトの名無しさん2011/02/26(土) 02:49:11.61
ちなみにこのスレッドの dat ファイルのサイズは UTF-8 で 113564 bytes だけど、
UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。
日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・
UTF-16 だと 129222 bytes で、UTF-16 の方がファイルサイズが大きくなるよ。
日本語の掲示板でこれなんだから、英語のテキストや数値データファイル、地図データ、
ログファイル等々、CJK 文字が殆ど入らないデータを UTF-16 で扱えばどれだけ
無駄が発生する事か・・・
234 :デフォルトの名無しさん2011/02/26(土) 02:58:37.03
GC付きのスイーツな言語処理系しか触ったことなくて、
文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。
ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ
>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよww
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよwww
文字列操作のコストがイメージできないからUTF-8とかUTF-32とか言えちゃうんだろ。
C, C++ とかで文字列処理のアルゴリズム組むとか、O記法の概念が分かれば、
「大抵のケースについてO(1)時間で処理できる」ということの重要性は分かるよ。
ついでに、メモリは増えたけど、アクセスはやたら遅いんだよ。昔から。
そんなにUTF-32使いたいならCPUが10GHzになってバス幅が1024bitになるまで寝てろ
>>233
それは外部エンコードディングの話じゃん
AAだらけのとことかでも比較してみろよww
しかもメモリをけちりたいくせに数値データを数値に変換する手間は惜しむのかよwww
235 :デフォルトの名無しさん2011/02/26(土) 03:06:04.80
>>234
何でこんな簡単な話を理解出来ない振りをするのか分からんけど、
1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?
それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・
何でこんな簡単な話を理解出来ない振りをするのか分からんけど、
1. dat ファイルは SJIS
2. それを内部エンコーディングが UTF-8 の処理系で読み込んだら 113564 bytes になる
3. UTF-16 の処理系で読み込んだら 129222 bytes になる
4. 非効率なのはどっち?
それ以外の下らない突っ込みにも返事して欲しい?
君の永遠に納得しないゲームに付き合う理由も無いけどね・・・
237 :デフォルトの名無しさん2011/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はもっと
使いものにならない。
話だったと思うんだが。
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はもっと
使いものにならない。
240 :デフォルトの名無しさん2011/02/26(土) 03:20:38.04
横からごめんよ。
よく分からんが、ここで争ってる文字コードは、どこで使う文字コード?
バージョン管理システム内だけで使う文字コードじゃないの?
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話?
よく分からんが、ここで争ってる文字コードは、どこで使う文字コード?
バージョン管理システム内だけで使う文字コードじゃないの?
それとも、各開発環境で使用してる文字コードを、
バージョン管理システムでは、わざわざ変換して保存するとかの話?
241 :デフォルトの名無しさん2011/02/26(土) 03:21:53.26
>>240
なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。
なんか内部エンコーディングと外部エンコーディングの区別もつかない奴が
暴れてるだけ。どの部分の文字コードの話とか全然話題になってない。
245 :デフォルトの名無しさん2011/02/26(土) 03:25:56.41
>>241
ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか?
ふーん
バージョン管理システム内で使う文字コード(ログとか)なら、
開発環境に合わせて、好きな文字コード選べた方が良いし、
開発環境で使用してる文字コードを、変換して保存するとか
トラブルの元にしかならないからやめて欲しいのは俺だけか?
252 :デフォルトの名無しさん2011/02/26(土) 03:36:34.42
ファイル名なんて、システム依存なんだから、
文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて?
文字コードを考えたって意味ないじゃん
むしろ、そのシステムで使えないファイル名を付ける奴が悪いってことじゃなくて?
254 :デフォルトの名無しさん2011/02/26(土) 04:02:39.82
utf8もutf16もutf32もサロゲートペア使って表せる範囲は全て同じでしょ?
基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの?
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…?
あぁ、結合文字とかも考えると、もっとめんどくさいのか…
基本的に処理なんて、変換位しかないし、一回書けば終わりなんだから
処理のしやすさなんて考えても意味ないじゃんって、突っ込んだら負けなの?
あと、変換とかで考えるとコードセパレート問題とか考える方が余程頭痛いけど…?
あぁ、結合文字とかも考えると、もっとめんどくさいのか…
255 :デフォルトの名無しさん2011/02/26(土) 06:50:22.82
utf16で盛り上がっているようですが、NTFSはutf16ではありません。ucs-2です
256 :デフォルトの名無しさん2011/02/26(土) 06:58:56.83
何その主張?
utf16じゃなくてutf-16とでも言いたいの?
それともucs-2はunicodeじゃないと言いたいの?
utf16じゃなくてutf-16とでも言いたいの?
それともucs-2はunicodeじゃないと言いたいの?
257 :デフォルトの名無しさん2011/02/26(土) 07:28:10.17
>>256
http://hibari.2ch.net/test/read.cgi/tech/1251208950/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なのか?という疑問もあるらしいし。
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
http://hibari.2ch.net/test/read.cgi/tech/1251208950/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なのか?という疑問もあるらしいし。
http://jp.rubyist.net/magazine/?0025-Ruby19_m17n#f07
258 :デフォルトの名無しさん2011/02/26(土) 07:30:25.22
>>256
http://hibari.2ch.net/test/read.cgi/tech/1251208950/472
472 名前:デフォルトの名無しさん [sage]: 2010/11/28(日) 03:40:53
>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。
http://hibari.2ch.net/test/read.cgi/tech/1251208950/472
472 名前:デフォルトの名無しさん [sage]: 2010/11/28(日) 03:40:53
>468
Windows SDKが定義する16bitのWCHARという型って意味でWCHARって書いたんだけど、紛らわしかったか。すまん。
UNIXのファイル名がバイト列に過ぎないのと同様に、生き別れのサロゲートペアなんかも入れられたはず。BOMやU+FFFFも入るかも。
259 :デフォルトの名無しさん2011/02/26(土) 07:31:18.33
>>257
つ UTF-16 == UCS/Unicode Transformation Format 16
つ UTF-16 == UCS/Unicode Transformation Format 16
260 :デフォルトの名無しさん2011/02/26(土) 10:19:28.28
内部コードがUTF-いくつなんてどうでもいいだろ。
外から見て差が出るところを話そうぜ……。
外から見て差が出るところを話そうぜ……。
261 :デフォルトの名無しさん2011/02/26(土) 10:30:56.66
>>260
うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの?
うん。
bzrはいつになったら、コンソールでのエラーメッセージなどが日本語になるの?
262 :デフォルトの名無しさん2011/02/26(土) 10:34:13.89
bzrのアンチ活動とか不毛すぎるだろ……
263 :デフォルトの名無しさん2011/02/26(土) 10:37:46.68
>>262
svn/hgはメッセージ日本語化されているよ
svn/hgはメッセージ日本語化されているよ
264 :デフォルトの名無しさん2011/02/26(土) 10:41:05.75
自分が使う時にはいらないが、素人に使わせる事ような場合はメッセージが
日本語化されていると嬉しいかもしれんなぁ。
日本語化されていると嬉しいかもしれんなぁ。
266 :デフォルトの名無しさん2011/02/26(土) 10:55:58.34
どんだけdisっても、git、hg、bzrの三者は、向こう十年は使われ続ける体制ができちゃったし、
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
気に入らない物が残っちゃてご愁傷さまとしか言いようがない。
次の十年に向けての啓蒙活動を頑張ってください。
>>264
素人ならGUI使わせるんじゃないかな。
267 :デフォルトの名無しさん2011/02/26(土) 11:13:32.83
>>266
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
そして、素人のwindiff、kdiffが化けますというクレームに、玄人が対応できていません、と答えるのですね
268 :methane2011/02/26(土) 12:12:01.68
>>261
そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
そろそろi18nしたいな。bzr-2.4までにできればやるよ。
>>267
bzr qdiff は、ファイルのエンコーディングをGUI上で選択できる
ようにはしておいた。玄人は素人にエンコーディングを教えて
あげてください。
269 :デフォルトの名無しさん2011/02/26(土) 12:42:29.67
>>268
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね?
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね?
WindowsでCP932で表すことができないファイル名のファイルはwindiff、kdiff3立ち上げられないよね?
cmd.exeでdiffしたとき、ファイルの中身がutf-8だった場合、激しく化け化けになるよね?
270 :methane2011/02/26(土) 15:15:05.28
>>269
前者は何とかする予定。
後者はさすがに無理ゲー(勝手にdiffの出力を変えたらpatchが動かない)なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
前者は何とかする予定。
後者はさすがに無理ゲー(勝手にdiffの出力を変えたらpatchが動かない)なので
プラグイン作ってオプションで回避するかな。
俺は | gvim - で見てる。
271 :デフォルトの名無しさん2011/02/26(土) 15:23:25.20
>>270
ということは、bzrのパッチもLinuxではロケール依存なのですね?
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね?
ということは、bzrのパッチもLinuxではロケール依存なのですね?
Windowsで作成されたパッチをLinuxであてるには、ja_JP.SJISでチェックアウトしないといけないのですね?
272 :methane2011/02/26(土) 15:37:40.65
>>271
何処をどう読めばそうなるんだろう…?
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
何処をどう読めばそうなるんだろう…?
ファイル名をロケール関係なく出力するからwindowsのコマンドプロンプトに
utf-8のファイルの内容を出力すると化けるんであって、それをリダイレクトで
patchファイルにしてLinuxに持って行ってpatchできるよ。
ただし、ファイル名はロケール依存になっちゃってるから、日本語ファイル名の
patchを作るときにはdiffは使えなくて、代わりにbundleという形式を使う。
265 :デフォルトの名無しさん2011/02/26(土) 10:55:44.74
>264
素人がコンソールで使うわけ無いだろ。GUI必須。
素人がコンソールで使うわけ無いだろ。GUI必須。
273 :methane2011/02/26(土) 15:38:21.18
あ、間違えた。
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
s/ファイル名をロケール関係なく/ファイルの内容をロケール関係なく/
274 :デフォルトの名無しさん2011/02/26(土) 15:42:10.39
bzrのcmd.exeの標準出力はCP932だよね?
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか?
ファイル名がCP932でファイルの中身がUTF-8の場合。
これを化けずにどうやって読むのでしょうか?
275 :methane2011/02/26(土) 15:46:43.42
>>274
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
そのケースではファイル全体を化けないように観るのは無理。
GUI使うかコマンドラインでも変換するプラグインを使って。
276 :デフォルトの名無しさん2011/02/26(土) 15:50:34.51
>>275
そのプラグインとは?
そのプラグインとは?
277 :methane2011/02/26(土) 16:18:29.23
278 :デフォルトの名無しさん2011/02/26(土) 16:49:58.73
UTF-256とか作っちまえよ
279 :デフォルトの名無しさん2011/02/26(土) 16:52:14.55
280 :デフォルトの名無しさん2011/02/26(土) 18:07:45.87
使える文字が増えれば良い訳じゃない
増えたら、増えたで、また、やっかいな問題が出てくるもんだ
増えたら、増えたで、また、やっかいな問題が出てくるもんだ
282 :デフォルトの名無しさん2011/02/26(土) 20:26:39.66
どでもいいんだが, プロジェクトが Unix 前提で構築されてて
ファイル名の銘々規則が
<module-name>:<function>.<ext>
な, VCS に MS Windows でつないでファイル名が
読めないって騒ぐのはよしてほしい
はなっから命名規則がやばいんで Windows からみると,
まともなファイル名は見えないって言ってるのにw
ファイル名の銘々規則が
<module-name>:<function>.<ext>
な, VCS に MS Windows でつないでファイル名が
読めないって騒ぐのはよしてほしい
はなっから命名規則がやばいんで Windows からみると,
まともなファイル名は見えないって言ってるのにw
284 :デフォルトの名無しさん2011/02/27(日) 01:03:08.98
最近の本を見るとbzrを以上に推してるな
最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた
だから他の分散管理はもっとがんばれ
勢いがいないぞ
最近の本で言えばプログラマが覚えるべき○○の事とかも最初にbzrの名前が挙がってた
だから他の分散管理はもっとがんばれ
勢いがいないぞ
286 :デフォルトの名無しさん2011/02/27(日) 05:42:50.73
>>284
git, hgの本は売っているけど、bzrの本は売ってる?
git, hgの本は売っているけど、bzrの本は売ってる?
288 :デフォルトの名無しさん2011/02/27(日) 06:23:31.25
>>284
git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない
TortoiseHg 2.0 が3月1日に出る予定なので、hgは勢いつくかもしれない
いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな?
git, hg本体は枯れていて安定期に入ってるから勢いが無いようにみえるかもしれない
TortoiseHg 2.0 が3月1日に出る予定なので、hgは勢いつくかもしれない
いろいろ目玉はあるけど、このスレ的には、MacOSX対応かな?
290 :デフォルトの名無しさん2011/02/28(月) 17:37:23.77
>284
全然見ないよ。
最近は、本そのものをね。
bzrは、btrfsと同じで名前が途轍もなく格好悪いので
geek心をくすぐらないと思う
>>288
OSX対応って・・・MacHgで十分だったんだけど・・・
Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・
全然見ないよ。
最近は、本そのものをね。
bzrは、btrfsと同じで名前が途轍もなく格好悪いので
geek心をくすぐらないと思う
>>288
OSX対応って・・・MacHgで十分だったんだけど・・・
Finderに統合って、結構鬱陶しいってことがSubversionの時に分かったし・・・
287 :デフォルトの名無しさん2011/02/27(日) 05:47:23.01
売ってない気がする
bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね
bzrはアジャイル設計とかそういうプロジェクト管理系の本でよく見かけるようになったね
291 :デフォルトの名無しさん2011/04/01(金) 03:23:44.79
Monotone が 1.0 になったみたいだけど、国際化対応とかユーザー認証の暗号化とかあるし、
期待してもいいんだろうか。
期待してもいいんだろうか。
293 :デフォルトの名無しさん2011/04/02(土) 20:48:33.91
431 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 21:52:13
>430
>リポジトリデータはSQLiteで管理する。
キモの部分が他人任せかよ。
432 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:09:21
キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない
433 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:14:39
http://po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。
>430
>リポジトリデータはSQLiteで管理する。
キモの部分が他人任せかよ。
432 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:09:21
キモかどうかは判断が分かれるな
バックエンドの処理については実装部分の話で速度に影響する
もしmonotoneが速かったらGITもMercurialも産まれてなかったかもしれない
433 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:14:39
http://po3a.blogspot.com/2007/12/subversion.html
> もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
> ほんとに。連中は「本物のデータベース」を使っているよ。
> 「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
> 使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
> これらすべての設計上の決定のために、できてきた結果はゲロゲロで
> 保守不可能なカオスだ。
294 :デフォルトの名無しさん2011/04/02(土) 20:49:36.36
434 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:29:00
ケチョンケチョンだなw
Cが至高なのは同意だが
435 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:42:13
Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。
436 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:42:59
そこは別にいいんじゃね?
437 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:44:07
しょっちゅう使うツールは速いが正義なんだよなぁ。
438 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:48:02
で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ?
公開鍵がどうこうのあたり?
439 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 23:00:55
Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。
ケチョンケチョンだなw
Cが至高なのは同意だが
435 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:42:13
Linus は最初 BitKeeper に変る SCM でMonotone を最有力に挙げていたが、
動作速度が遅いから Linus版 Monotone としてGitを作ったんだよな。
436 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:42:59
そこは別にいいんじゃね?
437 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:44:07
しょっちゅう使うツールは速いが正義なんだよなぁ。
438 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 22:48:02
で、Monotoneは、user-visibleなとこでは、どの辺に新規性があるわけ?
公開鍵がどうこうのあたり?
439 名前:デフォルトの名無しさん [sage]: 2010/11/07(日) 23:00:55
Monotone はファイル名をUTF-8に変換して管理してる。
これは Git に持ち込まなかった概念で、速度を犠牲にしたバカげた設計だと
Linus は思ったのだろう。
295 :デフォルトの名無しさん2011/04/02(土) 23:53:55.07
速度を犠牲にしたバカげた設計をしてしまったのがSubversionとBazaarかw
296 :デフォルトの名無しさん2011/04/03(日) 01:08:09.17
301 :デフォルトの名無しさん2011/04/06(水) 22:47:50.27
>>296
> The two leading distributed version control systems are Git and Mercurial,
> with Darcs, Bzr and others much less widely used.
> Typically the systems are used by their language implementers;
> Darcs, by Haskell developers, Mercurial by Python developers and Git for C developers.
> The two leading distributed version control systems are Git and Mercurial,
> with Darcs, Bzr and others much less widely used.
> Typically the systems are used by their language implementers;
> Darcs, by Haskell developers, Mercurial by Python developers and Git for C developers.
297 :デフォルトの名無しさん2011/04/03(日) 02:51:43.75
SubversionはCなのに遅いからなぁ。あの遅さはUTF-8のせいだけじゃないんじゃないか。
まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。
まあでもCVSの代替としては長く使わせてもらったし、あの時点では最良だったと思う。
298 :デフォルトの名無しさん2011/04/03(日) 03:14:47.45
結局、どれもこれも帯に短し襷に長し、決定版と言うのはないのかね?
300 :デフォルトの名無しさん2011/04/03(日) 21:26:45.16
帯も襷もあるが、襷としても使える帯は無いし、
帯としても使える襷は無い、ということか。
帯としても使える襷は無い、ということか。
302 :デフォルトの名無しさん2011/04/08(金) 10:18:19.21
Subversionのしかもwindows版TortoiseSVNから使い始めた俺は
遅くてもこんな物なんだろうと思っているからきっと幸せ。
つーか、俺、最初に手をつけた物が良いという思い込みが強くて
なかなか移行できない性格で難儀。
遅くてもこんな物なんだろうと思っているからきっと幸せ。
つーか、俺、最初に手をつけた物が良いという思い込みが強くて
なかなか移行できない性格で難儀。
303 :デフォルトの名無しさん2011/04/08(金) 11:24:36.98
>>302
VSSに触らなくて良かったな
VSSに触らなくて良かったな
304 :デフォルトの名無しさん2011/04/08(金) 14:53:29.00
パスが含まれているようなファイルはどう管理したらいいのですか?
オープンなリポジトリにそのままコミットするわけにはいかないと思うので。
オープンなリポジトリにそのままコミットするわけにはいかないと思うので。
305 :デフォルトの名無しさん2011/04/08(金) 14:56:19.22
2文字読んでpathかと思ったらpasswordか。
* sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。
* 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。
など。
* sensibleなデータだけ別ファイルになるような構成にして、リポジトリに入れないようにする。
* 暗号化したものを入れておいてデコード手段はリポジトリに入れないようにする。
など。
307 :デフォルトの名無しさん2011/04/08(金) 17:35:21.28
なるほど・・・参考になりました!
ありがとうございます。
ありがとうございます。
308 :デフォルトの名無しさん2011/04/13(水) 14:20:21.44
これからバージョン管理を導入しようと思い調べたのだけれど、
有名どころだけでも結構あるんだね。
数人で1プロジェクトのソースが100ファイルで合計1MBに満たない
ようなレベルならTortoiseSVNあたりで十分かな?
ネット上の情報も一番多い感じなので、取っつきやすいと感じた。
それとも、今から覚えるなら、こっちにしておけっていうのあります?
有名どころだけでも結構あるんだね。
数人で1プロジェクトのソースが100ファイルで合計1MBに満たない
ようなレベルならTortoiseSVNあたりで十分かな?
ネット上の情報も一番多い感じなので、取っつきやすいと感じた。
それとも、今から覚えるなら、こっちにしておけっていうのあります?
309 :デフォルトの名無しさん2011/04/13(水) 14:33:52.97
やっぱsvnが無難でしょ。
TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。
さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。
何だかんだ言って、インテグレーションの出来が違いすぎる。
TortoiseSVNってことはWin環境なんだろうけど、サーバー側はVisualSVN Serverを勧めておく。
さらにVisual Studio使ってて金が出せるなら、AnkhSVNよりVisualSVNがお勧め。
何だかんだ言って、インテグレーションの出来が違いすぎる。
310 :デフォルトの名無しさん2011/04/13(水) 15:48:40.56
>>309
ありがとう。
ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。
名前が似てるけど、全然別物なのか。
ありがとう。
ちょっとVisualSVN Server、VisualSVNこの辺を調べてくる。
名前が似てるけど、全然別物なのか。
311 :デフォルトの名無しさん2011/04/13(水) 19:54:25.29
VisualSVNそんなに良いの?いくらするんだっけ?
AnkhSVNもまあまあ悪くはないかと思ったけど
AnkhSVNもまあまあ悪くはないかと思ったけど
312 :デフォルトの名無しさん2011/04/13(水) 23:17:07.73
AnkhSVNでも入れないよりは全然マシ。
今やってるプロジェクトはそれすら使っていないから
VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。
今やってるプロジェクトはそれすら使っていないから
VS上でファイル名変更されると履歴が参照できずバージョン管理の意味が無くなってる。
313 :デフォルトの名無しさん2011/04/14(木) 02:06:48.18
Mercurialなら、名前変更の推定処理が出来るのに。
426 :デフォルトの名無しさん2011/05/02(月) 12:10:01.43
>>313
そのwprintfはwcstombsしてるんだろ。
まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。
そのwprintfはwcstombsしてるんだろ。
まずWriteConsoleWでUTF-16のまま無変換出力を試みる
→エラーになったらコンソール以外にリダイレクトされてるから
保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile
がWindowsでの正しいUnicode対応コンソールアプリの作り方。
428 :デフォルトの名無しさん2011/05/02(月) 12:29:52.71
>>426
Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
http://mercurial.selenic.com/wiki/EncodingStrategy#Functions
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。
Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。
http://mercurial.selenic.com/wiki/EncodingStrategy#Functions
にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。
429 :デフォルトの名無しさん2011/05/02(月) 12:35:44.01
>>428
すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。
すまん、アンカーミスなんだ。
元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。
430 :デフォルトの名無しさん2011/05/02(月) 12:50:32.48
>>429
バージョン管理と何の関係があるの?
バージョン管理と何の関係があるの?
314 :デフォルトの名無しさん2011/04/14(木) 02:18:52.78
Hgもリネームは推定なのか。Gitもそう。
315 :デフォルトの名無しさん2011/04/14(木) 05:50:39.51
>>314
hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。
ファイルの移動はリポジトリに記録される。
hg addremoveコマンドが推定。"--similarity 類似度"でパーセントを指定できる。
ファイルの移動はリポジトリに記録される。
316 :デフォルトの名無しさん2011/04/14(木) 14:42:44.77
>>315
え、移動はリポジトリに記録される、けどリネームは推定なの?
リネームと移動は同じじゃないか…?
え、移動はリポジトリに記録される、けどリネームは推定なの?
リネームと移動は同じじゃないか…?
317 :デフォルトの名無しさん2011/04/14(木) 14:57:42.25
>>316
hgのファイルの移動はコピーして削除。これはリポジトリ(マニフェスト)に記録される。
コピーしたものもマージ時に反映される。
ファイルの移動はhg renameコマンドを使うのが一般的。
hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、
パラメータ無しで追加、削除を自動的に認識するコマンド。
hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、
ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。
hgのファイルの移動はコピーして削除。これはリポジトリ(マニフェスト)に記録される。
コピーしたものもマージ時に反映される。
ファイルの移動はhg renameコマンドを使うのが一般的。
hg addとhg removeコマンドがあって、それぞれ、ファイルを追加したとき、削除したとき、
パラメータ無しで追加、削除を自動的に認識するコマンド。
hg addremoveはそれを合体させたもので、--similarity 100がデフォルトの値で、
ファイルが改変されていないものは移動と認識されて、commit時にそれが反映される。
318 :デフォルトの名無しさん2011/04/14(木) 15:11:44.05
>>317
>これはリポジトリ(マニフェスト)に記録される
「コピーして削除」のみならず「移動」としての情報が記録されるということ?
つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな?
それとも--similarity 100の時だけ「移動」として特別に記録?
>これはリポジトリ(マニフェスト)に記録される
「コピーして削除」のみならず「移動」としての情報が記録されるということ?
つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな?
それとも--similarity 100の時だけ「移動」として特別に記録?
319 :デフォルトの名無しさん2011/04/14(木) 15:46:11.01
>>318
> >これはリポジトリ(マニフェスト)に記録される
> 「コピーして削除」のみならず「移動」としての情報が記録されるということ?
リポジトリ(マニフェスト)には、コピーしたというのと削除したというのが別々に記録される。
aaa -> bbb
・bbbはaaaのコピー
・aaaは削除
> つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな?
> それとも--similarity 100の時だけ「移動」として特別に記録?
hg addremoveがファイルの移動をコピーと削除として判断する。
hg status のオプション"--copies"で確認可能。
この結果をcommitで確定させる。
> >これはリポジトリ(マニフェスト)に記録される
> 「コピーして削除」のみならず「移動」としての情報が記録されるということ?
リポジトリ(マニフェスト)には、コピーしたというのと削除したというのが別々に記録される。
aaa -> bbb
・bbbはaaaのコピー
・aaaは削除
> つまりリネームも移動もsimilarityをリポジトリに記録出来るってことかな?
> それとも--similarity 100の時だけ「移動」として特別に記録?
hg addremoveがファイルの移動をコピーと削除として判断する。
hg status のオプション"--copies"で確認可能。
この結果をcommitで確定させる。
320 :デフォルトの名無しさん2011/04/14(木) 17:17:45.25
>>319
なるほど、そうなるとsvnと似たやり方かな。
Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。
全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。
なるほど、そうなるとsvnと似たやり方かな。
Gitはそういうの一切記録しなくて、履歴を表示する時に動的に分析してる。
全く同時期に同じ目的で開発されたものだけど、けっこう違うんだねえ。
322 :デフォルトの名無しさん2011/04/25(月) 09:25:35.79
ひさびさにTortoiseHgをあぷでとした
チャンクごとのコミットが面倒なことになってないかい
なんだよこれ
チャンクごとのコミットが面倒なことになってないかい
なんだよこれ
323 :デフォルトの名無しさん2011/04/25(月) 10:18:19.53
>>322
TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、
1.1.xの最新版を使うことをお勧めします。
https://bitbucket.org/tortoisehg/stable/downloads
TortoiseHg 2.0の大幅なユーザインターフェースの更新に抵抗がある方は、
1.1.xの最新版を使うことをお勧めします。
https://bitbucket.org/tortoisehg/stable/downloads
324 :デフォルトの名無しさん2011/04/25(月) 10:37:51.10
そうですか
よくみたらメジャーアップデートしてたんだ
日本語の方マニュアルやリリースノートも更新してくれればなあ!
よくみたらメジャーアップデートしてたんだ
日本語の方マニュアルやリリースノートも更新してくれればなあ!
325 :デフォルトの名無しさん2011/04/25(月) 20:04:58.45
Git 1.7.5がリリース、メッセージの国際化へ一歩
http://www.atmarkit.co.jp/news/201104/25/git.html
http://www.atmarkit.co.jp/news/201104/25/git.html
387 :デフォルトの名無しさん2011/04/28(木) 11:16:05.67
書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、
Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。
Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。
326 :デフォルトの名無しさん2011/04/25(月) 21:03:39.77
日本語ファイルが使えるならgit一択なのにな
327 :デフォルトの名無しさん2011/04/25(月) 21:06:26.08
>>326
使えるよ
使えるよ
328 :デフォルトの名無しさん2011/04/25(月) 21:09:21.90
あれ、そなの?
Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの?
Win、Mac、Linuxの環境でsvnのように何の問題もなくなったの?
329 :デフォルトの名無しさん2011/04/25(月) 21:11:41.67
>>328
さて、svnのどこが何の問題が無いのでしょうか?
さて、svnのどこが何の問題が無いのでしょうか?
331 :デフォルトの名無しさん2011/04/25(月) 23:10:29.20
>>329
日本語のファイルの取り扱いが問題ありません
他はすべて日本語の扱いに問題有り
日本語のファイルの取り扱いが問題ありません
他はすべて日本語の扱いに問題有り
330 :デフォルトの名無しさん2011/04/25(月) 21:37:51.11
Git一択というほどGitいいのか。
今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。
今、MercrialとBazaarを試用しているけれど、Gitも試してみるか。
337 :デフォルトの名無しさん2011/04/26(火) 00:20:04.65
svnは対応はできていません。
http://subversion.tigris.org/issues/show_bug.cgi?id=2464
bzrもだめです。
https://bugs.launchpad.net/bzr/+bug/172383
http://subversion.tigris.org/issues/show_bug.cgi?id=2464
bzrもだめです。
https://bugs.launchpad.net/bzr/+bug/172383
342 :デフォルトの名無しさん2011/04/26(火) 09:05:53.42
>>337
Mac ports の svn は対応パッチ済みです。
bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている
ケースは解決されています。
Mac OS X が出るまではみんなSubversionの(スピードはともかく)ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。
Mac ports の svn は対応パッチ済みです。
bzr も完全に解決したかの確認がまだだけど、2.3で現在までに報告されている
ケースは解決されています。
Mac OS X が出るまではみんなSubversionの(スピードはともかく)ファイル名の
扱いには満足していたんだし、Mac OS X の問題もとりあえず対応策が広まったし、
Unicodeでファイル名を扱うことを危険だと叫んでるのはただのFUD
Unicodeはすべての問題を解決してくれるわけではないが、文字コード周りの問題に
対するコストパフォーマンスの高い対応策。
343 :デフォルトの名無しさん2011/04/26(火) 09:15:25.50
>>342
GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD
GitとMercurialでファイル名に「ユニコード」が使えないという誤解を相変わらずバラ撒いている方がFUD
345 :デフォルトの名無しさん2011/04/26(火) 09:22:06.40
>>343
このスレでだれがそんなFUDを言ってる?
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD?
このスレでだれがそんなFUDを言ってる?
それとも、Mac OS X のNFD(モドキ)正規化問題に対応できてないというのがFUD?
346 :デフォルトの名無しさん2011/04/26(火) 09:22:54.02
>>342
> Mac OS X が出るまではみんなSubversionの(スピードはともかく)ファイル名の
> 扱いには満足していたんだし、
満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。
> Mac OS X が出るまではみんなSubversionの(スピードはともかく)ファイル名の
> 扱いには満足していたんだし、
満足なんかしてないよ。
波ダッシュとかの問題とか考えれば、永続的にメンテが必要なシステムに
ファイル名変換が行われるものなんか使わないよ。
350 :デフォルトの名無しさん2011/04/26(火) 09:30:01.93
>>346
たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。
WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。
たしかに、みんなは言い過ぎだな。
でも、波ダッシュ問題もWindowsだったらUTF-16で、LinuxやMacではUTF-8で扱えば
一切Shift-JISとの変換なんて起こらないし、多くの人は一部の文字が使えない
ことよりもリポジトリ内に複数の文字エンコーディングのファイル名が混ざる事や
たくさんの独自パッチ済みクライアントが乱立する方が管理が面倒だと感じて
CVSからSubversionへの変化を喜んでいた。
WinCVS日本語版でみんなこのオプション使いましょーねというルール決めても時々
設定間違ってコミットする人がいてリポジトリの内容が文字化けしていた時代に
戻りたいという人がどれくらいいるか。
344 :3412011/04/26(火) 09:21:33.19
言い忘れたけど上の画像はOSXね
347 :デフォルトの名無しさん2011/04/26(火) 09:23:56.85
>>344
Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない?
Windowsでばーかというファイルを作成してMacでチェックアウトして
編集せずに git diff したら、何もしてないのにファイル名が変更されたって
報告されない?
349 :デフォルトの名無しさん2011/04/26(火) 09:27:11.56
>>347
GitHubにでもレポ作ってくれれば試すよ
興味あるし
GitHubにでもレポ作ってくれれば試すよ
興味あるし
351 :デフォルトの名無しさん2011/04/26(火) 09:30:43.31
>>347
gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー
gitは知らんが、hgはMacユーザがaddremoveすればWin/Linux/Macユーザみんなハッピー
352 :デフォルトの名無しさん2011/04/26(火) 09:34:07.00
353 :デフォルトの名無しさん2011/04/26(火) 09:35:06.00
>>351
Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ?
Windows の hg って utf-8 ファイル名まともに使えるようになったんだっけ?
354 :デフォルトの名無しさん2011/04/26(火) 09:36:39.26
>>353
cygwin、fixutf8
cygwin、fixutf8
355 :デフォルトの名無しさん2011/04/26(火) 09:37:13.47
>>351
あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。
あと、その方法だとLinux/Winユーザーがpullしてファイル名がNFDになると、
コマンドラインからファイル名指定するときに普通に日本語入力システムで
変換するとNFCになっちゃうからファイル名指定できなくて全然ハッピーじゃない。
356 :デフォルトの名無しさん2011/04/26(火) 09:39:58.20
>>354
fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫?
cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。
fixutf8 ってもう安定して使えるのかな。TortoiseHGとの連携大丈夫?
cygwinを使う方法については、cygwinが必要だというのを明示せずに
「utf-8使えるよ」というのは、まどかシステム以前のQBのような気がするので、
ちゃんと「cygwin使えばutf-8使えるよ」と言って欲しい。
357 :デフォルトの名無しさん2011/04/26(火) 09:40:24.04
>>355
hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。
hgでコマンドラインでファイル名指定するのはhg log FILEぐらい。
hg add/remove/addremoveは自動認識するし。
358 :デフォルトの名無しさん2011/04/26(火) 09:43:16.46
>>357
チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。
チェックアウトしたファイルを開こうとして
$ vim ばーか.txt
ってやる場合を考えると、hgで直接ファイル名指定する機会が少ないというのは
リポジトリ内にNFDを突っ込む問題の一部しかカバーできてないと思う。
360 :デフォルトの名無しさん2011/04/26(火) 09:49:21.95
>>358
たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・
たしかに「ば」が先頭だとシェル補完が厳しいなぁ・・・
361 :デフォルトの名無しさん2011/04/26(火) 09:49:36.10
>>352
git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ
git diffだと何も表示されないがgit statusだとUntracked fileとして表示されるね
WindowsのMsysGitを使った場合だとLinuxやMacではこういうことが起きるのか
勉強にはなったが、どうしようかなあ
359 :デフォルトの名無しさん2011/04/26(火) 09:47:23.72
まとめ
日本語を使うのなら、、
集中型ならsvn
分散型ならbzr
日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg
日本語を使うのなら、、
集中型ならsvn
分散型ならbzr
日本語は使わないのなら、、
速いのが好きならgit
googleが好きならhg
362 :デフォルトの名無しさん2011/04/26(火) 10:40:10.09
ソースコードの中身ならまだしも、ファイル名に日本語とか情弱の極みだろ
363 :デフォルトの名無しさん2011/04/26(火) 11:18:24.43
まだ>>362みたいなことを言ってる馬鹿がいるんだな
364 :デフォルトの名無しさん2011/04/26(火) 11:23:43.49
ぶっちゃけどのバージョン管理システムかの問題じゃなくてWindowsの問題だよね
369 :デフォルトの名無しさん2011/04/26(火) 14:22:22.90
>>364
Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。
Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。
どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず
ファイルをアップロードするときとか、zipファイルの中身とかいろんな
場面に影響するので凶悪。
370 :デフォルトの名無しさん2011/04/26(火) 14:49:34.62
>>369
ファイル名の話してんのに何言ってんの?
論点のすり替え乙
ファイル名の話してんのに何言ってんの?
論点のすり替え乙
371 :デフォルトの名無しさん2011/04/26(火) 16:19:32.78
>>370
ファイル名の話だよ?
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。
ファイル名の話だよ?
Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。
Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。
366 :デフォルトの名無しさん2011/04/26(火) 13:08:35.45
自分、英語がプアなもんでファイル名に日本語が欠かせません!
英語にしてもそこそこ把握できる場合(予想)
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』
英語にしたら把握に時間がかかるか訳がわからない場合(予想)
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』
というような場合もあるんじゃないかな?
仮定、想像の話だけど。
英語にしてもそこそこ把握できる場合(予想)
『ワルプルギスの淫夢.txt』
『奴隷少佐ルクレツィア.txt』
英語にしたら把握に時間がかかるか訳がわからない場合(予想)
『目覚めると従姉妹を護る美少女剣士になっていた.txt』
『俺のフラグはよりどりみデレ.txt』
というような場合もあるんじゃないかな?
仮定、想像の話だけど。
367 :デフォルトの名無しさん2011/04/26(火) 13:36:52.35
確かにそうだな。
それはそれとして、そのtxtの中身について話をしたいのだが。
それはそれとして、そのtxtの中身について話をしたいのだが。
368 :デフォルトの名無しさん2011/04/26(火) 13:45:20.85
非実在テキストファイルですから。
何分、仮定、想像の話なので。
何分、仮定、想像の話なので。
372 :デフォルトの名無しさん2011/04/26(火) 16:23:47.02
厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを
のぞいたらWinXP (01年) だから、10年以上ではないな。
のぞいたらWinXP (01年) だから、10年以上ではないな。
374 :デフォルトの名無しさん2011/04/26(火) 16:24:26.87
Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。
376 :デフォルトの名無しさん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 に渡している。
Python はどちらでも扱えるようにしている。
open(u"ほげ") ならUnicode APIで、open("ほげ") ならASCII APIを使う。
bzrは前者、mercurialは後者を使ってる。
cygwin は、 fopen("ほげ"); すると、 "ほげ" を utf-8 でデコードして、
UTF-16にエンコードして、 CreateFileW に渡している。
405 :デフォルトの名無しさん2011/05/01(日) 14:39:55.41
gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ
バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの?
バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ
BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ
でもバイト列で扱う方針なら変換できないよね
localeに応じて変換するのだろうか
マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの?
377 :デフォルトの名無しさん2011/04/26(火) 16:31:31.57
>376
それがクソって言ってんの
それがクソって言ってんの
378 :デフォルトの名無しさん2011/04/26(火) 16:34:02.13
>>377
えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。
えー、これがクソならどうしろと、、、
C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で
すごく使いにくくなるんだけど。
Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと
思ってる。
379 :デフォルトの名無しさん2011/04/26(火) 17:11:59.63
というかそれならMercurialで問題になってるのは何なの
380 :デフォルトの名無しさん2011/04/26(火) 18:26:12.29
381 :デフォルトの名無しさん2011/04/26(火) 18:29:23.48
>>379
英語のwikiにはNTFSはUTF-16となっているが、実際は2バイトのバイト列。
UTF-16としては不正な値も格納される。
英語のwikiにはNTFSはUTF-16となっているが、実際は2バイトのバイト列。
UTF-16としては不正な値も格納される。
383 :デフォルトの名無しさん2011/04/28(木) 10:45:25.11
Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。
Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか?
Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき
やすいのは日本語対応が進んでいるBazaarでしょうか?
386 :デフォルトの名無しさん2011/04/28(木) 11:15:43.07
Windows onlyならhg、bzrのどちらでもいいと思う
でかいファイルを扱うならhgかな
でかいファイルを扱うならhgかな
389 :デフォルトの名無しさん2011/04/28(木) 11:19:07.53
分散だと日本語環境はbzrが独占状態なのよねぇ。
他は何をやってんのやら。
他は何をやってんのやら。
390 :デフォルトの名無しさん2011/04/28(木) 11:23:24.89
>>389
> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。
> 分散だと日本語環境はbzrが独占状態なのよねぇ。
> 他は何をやってんのやら。
「Windowsのファイルシステムの」日本語環境でしょ。
Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。
391 :デフォルトの名無しさん2011/04/28(木) 11:27:13.00
そうはいっても
○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ
○○支社向け.docとか
○○部長月間予定.xlsとか
いう日本語ファイル名って結構使うからねぇ
392 :デフォルトの名無しさん2011/04/28(木) 11:31:50.17
>>391
リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。
リポジトリを分ければ良い。
そういうファイルがあるところだけsvnにすれば良い。
svnはリポジトリを一ヶ所にするというのが一般的のようだが、
別に一ヶ所にする必要もない。
393 :デフォルトの名無しさん2011/04/28(木) 11:35:09.66
運用ポリシーで複数の管理システムを使うのはちょっとね
後々の事を考えてシンプルにしないとさ
後々の事を考えてシンプルにしないとさ
394 :デフォルトの名無しさん2011/04/28(木) 11:46:48.22
Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ?
395 :デフォルトの名無しさん2011/04/28(木) 11:48:38.19
>>394
CP932に無いUnicodeの文字も増えてきているからねえ・・・
CP932に無いUnicodeの文字も増えてきているからねえ・・・
396 :デフォルトの名無しさん2011/04/28(木) 14:21:26.83
○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。
どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。
どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。
そういうのはsvnでいいんじゃね。
397 :デフォルトの名無しさん2011/04/28(木) 14:50:19.02
398 :デフォルトの名無しさん2011/04/28(木) 15:39:09.50
>>397
分散型でlockとかwww
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル()とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。
分散型でlockとかwww
というのは釣りですが、それでワークフローがうまく回るなら良いですね。
特に仕事でアジャイル()とかだと分単位で作業が入り乱れるだろうから、
バグトラッカとかでやりとりするよりもスムーズかも知れない。
400 :デフォルトの名無しさん2011/04/28(木) 16:10:18.30
>>396
中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん
中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ
人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん
402 :デフォルトの名無しさん2011/04/28(木) 16:41:36.52
>>400
ワードとかエクセルのマージ作業はどうするの?
ワードとかエクセルのマージ作業はどうするの?
399 :デフォルトの名無しさん2011/04/28(木) 15:39:15.31
かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。
結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。
結局のところ、運用でごまかせって感じになっているのがなぁ。
誰だよ1バイト圏意外に住んでいるやつは。
403 :デフォルトの名無しさん2011/04/28(木) 16:43:59.18
それって別に分散かどうかは関係ないよね
404 :デフォルトの名無しさん2011/04/28(木) 16:49:45.42
>>403
マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ
マスターリポジトリにプッシュするまでもない物をとりあえず確認するために
個人のローカルリポジトリにアクセスしたりとか
個別相談受けて訂正する時にその人のローカル除いたりとか色々ある
メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ
406 :デフォルトの名無しさん2011/05/01(日) 15:02:14.19
根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。
やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。
それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)
やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。
それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。
gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。
(bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える)
408 :デフォルトの名無しさん2011/05/01(日) 15:23:53.14
>>406
> hgは単に開発者が無理解なだけだろ。
無理解とは思えないが。
http://mercurial.selenic.com/wiki/EncodingStrategy
cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。
> hgは単に開発者が無理解なだけだろ。
無理解とは思えないが。
http://mercurial.selenic.com/wiki/EncodingStrategy
cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。
bzrがcmd.exeでCP932の方が無理解だと思うが。
407 :デフォルトの名無しさん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の混在に慣れているが、これは日本の特殊事情
・欧米人はファイル名にCP1252(ISO-8859-1)が使えれば満足
・欧米人はLinuxでもファイル名はISO-8859-1を使っている
・Linux/UnixでロケールをUTF-8にしているのは日本人が主
・日本人はLinuxでEUC-JP/Shift_JIS/UTF-8の混在に慣れているが、これは日本の特殊事情
409 :デフォルトの名無しさん2011/05/01(日) 15:29:36.71
hgが叩かれる時のリンクじゃないかそれ
cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな
cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな
410 :デフォルトの名無しさん2011/05/01(日) 15:33:04.46
>>409
cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。
cmd.exeでwは使えない。
wprintf()がcp932とかcp1252の時にデータが欠損する。
411 :デフォルトの名無しさん2011/05/01(日) 15:35:38.99
>>409
bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。
bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。
412 :デフォルトの名無しさん2011/05/01(日) 15:37:30.80
使えるっての。
libcではなく自分でAPI呼べよ
libcではなく自分でAPI呼べよ
413 :デフォルトの名無しさん2011/05/01(日) 15:45:46.84
>>412
chcp 1252 して日本語混じりのをwprintfしたら何が出力される?
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。
chcp 1252 して日本語混じりのをwprintfしたら何が出力される?
だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては
正しいと思うが。
414 :デフォルトの名無しさん2011/05/01(日) 16:09:39.19
>>413
cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。
cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない
恐れがあるからという理由があったはず。
まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変
だからだろうけど。
CLIでunicode使いたかったら cygwin + minitty が最強。
415 :4142011/05/01(日) 16:10:15.09
>>412 だった。
417 :デフォルトの名無しさん2011/05/01(日) 16:15:14.84
>>412
出力って何のこと?diffとか?
出力って何のこと?diffとか?
419 :デフォルトの名無しさん2011/05/01(日) 19:18:31.36
>>413
さすがPowerShell ISEさんに隙はなかった・・・
さすがPowerShell ISEさんに隙はなかった・・・
420 :デフォルトの名無しさん2011/05/01(日) 19:21:34.79
>>419
Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。
Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、
PowerShellでも問題ない。これが正しい多言語化。
422 :デフォルトの名無しさん2011/05/01(日) 19:40:05.99
>>420
や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕
や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね
chcpコマンドがまともに機能するWin7標準のアプリ
従来の対話型コマンドが動作しないのが玉に瑕
423 :デフォルトの名無しさん2011/05/01(日) 20:00:58.60
>>422
PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。
PowerShell ISEってフルで言わないとだめなのか。
PowerShell ISEでMercurialでchcp 65001が最強。
424 :デフォルトの名無しさん2011/05/01(日) 20:09:01.55
>>423
うん、同意
うん、同意
427 :デフォルトの名無しさん2011/05/02(月) 12:10:24.54
>>413だった
416 :デフォルトの名無しさん2011/05/01(日) 16:14:13.63
UnicodeじゃないからUnicode版API使えないと言いつつ、
得体の知れないバイト列をANSI版APIに流し込む矛盾。
得体の知れないバイト列をANSI版APIに流し込む矛盾。
418 :デフォルトの名無しさん2011/05/01(日) 16:18:07.25
>>416
CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。
CP932と繁体字がASCIIと互換が無いから問題なのであって、
それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。
431 :デフォルトの名無しさん2011/05/04(水) 12:27:28.61
PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利
シェルとして使いにくいのが悲しい点
シェルとして使いにくいのが悲しい点
432 :デフォルトの名無しさん2011/05/17(火) 18:26:14.74
gitでリモートからdiffを取る機能が無いか
gitスレで聞いたんだが基本的に存在しないらしい。
svnから物凄い機能後退だと思うのだけど、
bzrとかhgとか或いは、darcsとかmonotoneでも
出来ないのが通常なのだろうか?svnでは
svn diff -r 123:456 svn://server/repo/trunk
とかで出来たと思うんだけど。
gitスレで聞いたんだが基本的に存在しないらしい。
svnから物凄い機能後退だと思うのだけど、
bzrとかhgとか或いは、darcsとかmonotoneでも
出来ないのが通常なのだろうか?svnでは
svn diff -r 123:456 svn://server/repo/trunk
とかで出来たと思うんだけど。
438 :デフォルトの名無しさん2011/05/17(火) 20:03:09.13
>>432みたいに新しい環境に拒絶反応示して興奮してる人って、後で恥ずかしくなったりしないのかね?
433 :デフォルトの名無しさん2011/05/17(火) 18:30:32.51
普通に考えたらdiff取るだけなのに毎回リモート見に行く必要があるsvnのほうが……
449 :デフォルトの名無しさん2011/05/18(水) 11:36:09.86
>>433
svnはリモート見に行く必要は無いんだが何いってんの?
svnはリモート見に行く必要は無いんだが何いってんの?
450 :デフォルトの名無しさん2011/05/18(水) 11:47:33.18
>>449
それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。
それは作業領域の話。
特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。
435 :デフォルトの名無しさん2011/05/17(火) 19:31:10.28
そうまでリモートに集約したいなら集中型のsvn使っとけば丁度良いよ
436 :デフォルトの名無しさん2011/05/17(火) 19:38:27.23
gitスレでも指摘されてるじゃないか
集中型じゃなくて分散型の思想について勉強してこいよ
集中型じゃなくて分散型の思想について勉強してこいよ
439 :デフォルトの名無しさん2011/05/17(火) 20:05:44.30
全成果プリントアウト(しかもシリアルプリンタで)がいいとおもうよ☆
440 :デフォルトの名無しさん2011/05/18(水) 00:19:30.76
いや、思想とかキモイです。
全部できないのか。酷い有様だな。
全部できないのか。酷い有様だな。
441 :デフォルトの名無しさん2011/05/18(水) 00:40:23.29
>>440
ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2
ssh gesonari@kimoi /usr/bin/git --git-dir=/svn/nou diff v0.1 v0.2
442 :デフォルトの名無しさん2011/05/18(水) 01:42:52.29
>>440
bzrはできる。
bzrはできる。
444 :デフォルトの名無しさん2011/05/18(水) 02:07:36.82
bzr は遅くて泣けてくる・・・
445 :デフォルトの名無しさん2011/05/18(水) 02:50:35.02
>>444
最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。
最近はそうでもないぞ。
といっても、Windows以外のユーザーが最新のbzrを使うにはソースから
インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。
454 :デフォルトの名無しさん2011/05/18(水) 18:58:53.50
>>445
いや、最近久し振りに使ったら遅くて泣けた・・・
いや、最近久し振りに使ったら遅くて泣けた・・・
455 :デフォルトの名無しさん2011/05/18(水) 19:33:53.77
>>454
毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった?手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない?
毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを
たくさんリポジトリに突っ込んじゃった場合だけ。
どんな状況で遅かった?手元のバージョンが良くてもサーバー側のバージョンが
悪かったりしない?
456 :デフォルトの名無しさん2011/05/18(水) 19:35:04.65
>>455
launchpadの遅さは異常
launchpadの遅さは異常
457 :デフォルトの名無しさん2011/05/18(水) 21:00:36.69
>>456
試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな?
試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの
ブランチに 16m37sec かかった。
速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の
1回だけだし、十分実用的な速度だと思う。
github や bitbucket に mysql のミラーないかな?
460 :デフォルトの名無しさん2011/05/18(水) 21:14:56.64
>>457
Linuxカーネルは?
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。
Linuxカーネルは?
bitbucketじゃないところにhgのミラーはあるよ。
確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、
単純比較できないかもしれないけど。
446 :デフォルトの名無しさん2011/05/18(水) 08:46:27.06
>使っていたソフトの開発元が svn+trac からgithubに
>変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな?
>変わってしまってかなり機能後退と分かりゲンナリです。
このソフトって何だろうね。
意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、
そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな?
448 :デフォルトの名無しさん2011/05/18(水) 09:23:18.91
分散型がキモかったらsvnを使い続けていれば良い。
svnがキモくてcvsを使い続けているところもある。
http://hibari.2ch.net/test/read.cgi/tech/1113141518/817-818
> 817 名前:デフォルトの名無しさん [sage]: 2010/02/08(月) 11:34:23
> やはりgitか・・・
> bzrはすぐすたれそうだしsvnはきもいからな・・・
>
> 818 名前:デフォルトの名無しさん [sage]: 2010/02/25(木) 14:38:53
> >>815
> CVS で十分なのは同感。svn が嫌なのも同意。
> 俺は分散型に関しては、Mercurial と Bazaar を検討中。
> 機能的には Mercurial だけど、Bazaar も結構追いつきつつある(と思う)。
> あんまり日本語ファイル管理することもないんだけどね。
svnがキモくてcvsを使い続けているところもある。
http://hibari.2ch.net/test/read.cgi/tech/1113141518/817-818
> 817 名前:デフォルトの名無しさん [sage]: 2010/02/08(月) 11:34:23
> やはりgitか・・・
> bzrはすぐすたれそうだしsvnはきもいからな・・・
>
> 818 名前:デフォルトの名無しさん [sage]: 2010/02/25(木) 14:38:53
> >>815
> CVS で十分なのは同感。svn が嫌なのも同意。
> 俺は分散型に関しては、Mercurial と Bazaar を検討中。
> 機能的には Mercurial だけど、Bazaar も結構追いつきつつある(と思う)。
> あんまり日本語ファイル管理することもないんだけどね。
451 :デフォルトの名無しさん2011/05/18(水) 12:03:07.87
svnの仕組みもしらないsvnマンセーがファビョッてると聞いて
458 :デフォルトの名無しさん2011/05/18(水) 21:08:09.61
24時間経過しても終わらない上にエラーで失敗したりするgit cvsimportとかと比べたら
16分とか一瞬だった
16分とか一瞬だった
461 :デフォルトの名無しさん2011/05/18(水) 21:16:19.31
time svn co http://svn.ruby-lang.org/repos/ruby/trunk/
real 0m18.214s
user 0m4.710s
sys 0m2.350s
time bzr branch lp:ruby
real 2m54.680s
user 1m29.770s
sys 0m1.500s
time git clone git://github.com/ruby/ruby.git ruby.git
real 2m42.831s
user 1m40.750s
sys 0m3.020s
git の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。
real 0m18.214s
user 0m4.710s
sys 0m2.350s
time bzr branch lp:ruby
real 2m54.680s
user 1m29.770s
sys 0m1.500s
time git clone git://github.com/ruby/ruby.git ruby.git
real 2m42.831s
user 1m40.750s
sys 0m3.020s
git の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。
463 :デフォルトの名無しさん2011/05/18(水) 21:27:44.57
>>461
初回はどー考えてもsvn有利だろw
初回はどー考えてもsvn有利だろw
481 :デフォルトの名無しさん2011/05/19(木) 08:05:41.81
>>461
githubのruby、trunk以外のブランチも入っているじゃん
githubのruby、trunk以外のブランチも入っているじゃん
484 :デフォルトの名無しさん2011/05/19(木) 11:17:07.01
>>481
うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。
まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。
うん、完全に同じ条件ではないとあとで気づいた。
だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
してはあながち的外れな比較でもないと思う。
まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、
一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を
作れるはずだけど面倒なのでパス。
485 :デフォルトの名無しさん2011/05/19(木) 18:55:21.88
>>484
> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
launchpadにアカウントを持っている人が一部の人では?
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。
> 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい
> 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも
> 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。
launchpadにアカウントを持っている人が一部の人では?
Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは
普通の感覚だと思うが。
486 :デフォルトの名無しさん2011/05/19(木) 19:06:38.32
>>484
> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。
git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの?
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。
> だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の
> ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と
> してはあながち的外れな比較でもないと思う。
git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、
柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの?
githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。
488 :4842011/05/19(木) 19:43:50.43
>>486
いやだから厳密な比較をしたいとかじゃなくて単に使い物にならないくらい遅いか
どうか調べたかっただけなんだって。
誰も bzr が git 並に速いなんて言ってないのに、そんなムキになって反論しなくても。
>>485
Launchpadからログオフしてmysql-serverをもう一回branchしてみた。
real 31m33.756s
user 11m9.130s
sys 0m8.110s
Launchpad自体がhttpサーバーが重くて遅いっぽいな。
でも、いつの間にかhttpでもスマートサーバーになってたらしくて、一晩かかるとか
ではない。mysqlでこの時間なら許容範囲内じゃない?
俺は、普段はmysqlよりも大分小さいプロジェクトで使ってるけど、全く問題ない速度で使えてる。
git と比べてて思ったのは、 git がステータス表示を常に高頻度で更新しててスピード感が
あるのに対して、 bzr の方がステータス表示の更新頻度が低いしちょくちょく止まる
(Launchpadからのレスポンスが遅いとずっと止まってることも、、、) ので見てて重そうに
感じた。実際の速度もまだまだgitに敵わないけど、遅いという印象を払拭するには
インタフェース面でもできることがありそう。
いやだから厳密な比較をしたいとかじゃなくて単に使い物にならないくらい遅いか
どうか調べたかっただけなんだって。
誰も bzr が git 並に速いなんて言ってないのに、そんなムキになって反論しなくても。
>>485
Launchpadからログオフしてmysql-serverをもう一回branchしてみた。
real 31m33.756s
user 11m9.130s
sys 0m8.110s
Launchpad自体がhttpサーバーが重くて遅いっぽいな。
でも、いつの間にかhttpでもスマートサーバーになってたらしくて、一晩かかるとか
ではない。mysqlでこの時間なら許容範囲内じゃない?
俺は、普段はmysqlよりも大分小さいプロジェクトで使ってるけど、全く問題ない速度で使えてる。
git と比べてて思ったのは、 git がステータス表示を常に高頻度で更新しててスピード感が
あるのに対して、 bzr の方がステータス表示の更新頻度が低いしちょくちょく止まる
(Launchpadからのレスポンスが遅いとずっと止まってることも、、、) ので見てて重そうに
感じた。実際の速度もまだまだgitに敵わないけど、遅いという印象を払拭するには
インタフェース面でもできることがありそう。
462 :デフォルトの名無しさん2011/05/18(水) 21:21:40.34
Emacs も酷いね。
465 :デフォルトの名無しさん2011/05/18(水) 21:45:41.86
>>462
$ time bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
real 17m46.033s
user 7m24.300s
sys 0m15.460s
2月辺りにはなんか問題あったらしいけど、改善されたらしいね。
$ time bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
real 17m46.033s
user 7m24.300s
sys 0m15.460s
2月辺りにはなんか問題あったらしいけど、改善されたらしいね。
466 :デフォルトの名無しさん2011/05/18(水) 22:00:37.84
time の履歴が流れちゃったけど、 savannah から git で emacs を clone
したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。
とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。
したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。
とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、
実用上問題にはならないだろ。
468 :デフォルトの名無しさん2011/05/18(水) 22:39:21.80
bzrの遅さはpull, push, merge全部が遅いってことでしょ。
インターネット越しじゃなくて、イントラネットでも。
インターネット越しじゃなくて、イントラネットでも。
477 :デフォルトの名無しさん2011/05/19(木) 00:53:13.72
マジレスするとGitとhgだろうな。どっちも似てるんだけどね。
GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。
GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。
479 :デフォルトの名無しさん2011/05/19(木) 01:05:32.02
github は本当に良く出来てるよね
必要な情報が無駄無く配置されていて使い勝手がとても良い
必要な情報が無駄無く配置されていて使い勝手がとても良い
480 :デフォルトの名無しさん2011/05/19(木) 02:24:14.68
gitはM$捨ててるからM$で遊んでる俺の選択肢にはなり得ない
482 :デフォルトの名無しさん2011/05/19(木) 08:10:45.02
>>480
http://code.google.com/p/msysgit/issues/detail?id=80#c77
http://repo.or.cz/w/git/mingw/4msysgit.git/shortlog/refs/heads/kb/unicode
http://repo.or.cz/w/git/mingw/4msysgit.git/commit/9205bfbef3dcd8d0361a04471c09d49e7a816b47
Mark unicode-related tests broken on msys
MSys bash doesn't support unicode at all. Testing a unicode-enabled git
with an encoding-agnostic bash cannot work.
This patch adds a new test function test_expect_success_unicode that tests
whether the shell is capable of passing unicode strings to another process.
If that works, the test is expected to succeed, otherwise it's expected to
fail.
http://code.google.com/p/msysgit/issues/detail?id=80#c77
http://repo.or.cz/w/git/mingw/4msysgit.git/shortlog/refs/heads/kb/unicode
http://repo.or.cz/w/git/mingw/4msysgit.git/commit/9205bfbef3dcd8d0361a04471c09d49e7a816b47
Mark unicode-related tests broken on msys
MSys bash doesn't support unicode at all. Testing a unicode-enabled git
with an encoding-agnostic bash cannot work.
This patch adds a new test function test_expect_success_unicode that tests
whether the shell is capable of passing unicode strings to another process.
If that works, the test is expected to succeed, otherwise it's expected to
fail.
483 :デフォルトの名無しさん2011/05/19(木) 08:17:10.66
gitもhgもutf-8に対応しているが、cmd.exe、MSysなど、MSの環境が糞なので、
まともに使えないってことだ。
まともに使えないってことだ。
506 :デフォルトの名無しさん2011/05/22(日) 15:25:09.20
>>483
それもひっくるめてgitが糞という評価になるんだが。
それもひっくるめてgitが糞という評価になるんだが。
489 :デフォルトの名無しさん2011/05/19(木) 20:05:06.73
「一晩」が実用の判断基準っておかしくない?
git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない?
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど?
git cvsimportやらgit-svnやらhgsubversionやらhg convertの最初の一回目が遅いのは当たり前。
だから、rubyのgithubみたいにミラーがあるんじゃない?
一回cloneすれば、その後のpullは差分だけど、そのpullもbzrは重いって指摘は
ぐぐればいっぱい出てくるけど?
491 :4842011/05/19(木) 20:56:45.77
>>489
厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。
bzrが実用にならないほど遅いという結論がでないとなにか困るの?
厳密な比較は面倒だからしないけど、きっとgitやhgよりも遅いんだろうな。
でも、俺は実用的な速度だと思ってるから使い続けてる。MySQLだって
あれだけ大きいプロジェクトで本当に使い物にならないほど遅かったら
とっくに乗り換えてるだろ。
bzrが実用にならないほど遅いという結論がでないとなにか困るの?
494 :デフォルトの名無しさん2011/05/19(木) 21:08:39.82
>>491
MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。
cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの?
cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね?
遅いものは主流になり得ないというのは歴史が証明していると思うけど。
MySQLは万人がハックしてパッチを送るタイプのプロジェクトでないでしょ。
Emacsのビルドにbzrに接続することを要求されて、それで、bzrの重さの認識が一気に浸透したと思うけど。
cvs、svnもゼロから始めるソースはそんなに重くないけど、
だんだん重くなるよね。
bzr信者は感覚が麻痺しているんじゃないの?
cvsがデファクトスタンダードでsvnがそれに置き換わるかと思われたけど、
svn離れが加速しているよね?
遅いものは主流になり得ないというのは歴史が証明していると思うけど。
490 :デフォルトの名無しさん2011/05/19(木) 20:55:28.09
> ぐぐればいっぱい出てくるけど?
これよそでは言うなよ恥ずかしいから
これよそでは言うなよ恥ずかしいから
492 :デフォルトの名無しさん2011/05/19(木) 21:06:22.87
bzrでもsvnに比べたら御の字じゃないの?
常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。
常識で考えてGitが速すぎるんだよ。
clone中のあのいかにも速そうなインジケータとか、最初に何となくやるであろう
Linuxカーネルのcloneの速度とか、最初から狙ってると思う。
493 :デフォルトの名無しさん2011/05/19(木) 21:06:25.30
実用になる人も居れば、ならない人も居るってだけじゃないの
今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ
今使ってる人は使い続ける理由が欲しいだろうけど、今使ってなければ
別に思い入れもないし、遅いのが嫌なら bzr は選ばないでしょ
495 :4842011/05/19(木) 21:28:36.76
信者呼ばわりか。まぁ否定はしないけど。
別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。
Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。
別に bzr が今後も主流になりえないかもしれないけど、Canonicalが潰れる
までは衰退することもないし、その時に考えるからいいよ。
俺は単に使い物にならないほど遅いとdisられがちだから本当にそんなに
遅いのか実験してみて、俺に取っては許容範囲だと判断しただけ。
Emacsの件はいろいろ不幸だった。savannahのサーバーのセットアップが
悪かったり、タイミング的に bzr 2.1 以前を使ってるユーザーがまだ
多かったり (lennyのデフォルトのbzrなんて1.5とかいう使い物にならない古さ)
したからな。
496 :デフォルトの名無しさん2011/05/19(木) 21:58:52.05
> cvs、svnもゼロから始めるソースはそんなに重くないけど、
> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。
> だんだん重くなるよね。
svn の場合、ファイルシステム(リポジトリのフォーマットのこと)によって違うよね。
以前の bdb の場合はリビジョンが増えてもチェックアウトは速かったけど、
今のデフォの fsfs の場合はリビジョンが増えるとチェックアウトが遅くなる。
その半面、 fsfs ではホットコピーが簡単になり、壊れなくなったけど。
497 :デフォルトの名無しさん2011/05/19(木) 22:46:24.95
信者認定プログラム:OS エディタ プログラミング言語 これにVCSが仲間入りか。
他にもキーボード配列とか文字エンコーディングとかあるけどね。
他にもキーボード配列とか文字エンコーディングとかあるけどね。
498 :デフォルトの名無しさん2011/05/19(木) 22:48:09.06
Emacsはbzrの重さの認識が万人に浸透するほどハックされてるのか
Lisperの一人として胸厚だわ
Lisperの一人として胸厚だわ
501 :デフォルトの名無しさん2011/05/20(金) 02:31:50.69
git>>>>bzr>>>>>>>>>>>>>>>>hg
今はこんな感じか。
hgの一時の勢いはどこへやら。
今はこんな感じか。
hgの一時の勢いはどこへやら。
504 :デフォルトの名無しさん2011/05/20(金) 10:26:12.38
>>501
2chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない?
2chのスレの勢いだとそうかもね。
hgの場合、日本語で語れる場所が他にもあるから。
そこで取り上げられていた、このスレに絶好のネタが2chでは取り上げられていないし、
住み分けができてるんじゃない?
502 :デフォルトの名無しさん2011/05/20(金) 10:02:32.19
windowsオンリーの環境で分散型を取り入れる時、
git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは!
git、hg、bzrからhgを選んで導入も終えてそこそこ使えるようになってきたのに、
だれだよオワコンとか言うのは!
503 :4842011/05/20(金) 10:23:37.27
>>502
hg いいと思うよ。そのうちWindowsでちゃんとUnicode API使えるようになりそうな気配だし。
hg いいと思うよ。そのうちWindowsでちゃんとUnicode API使えるようになりそうな気配だし。
505 :5042011/05/20(金) 10:27:50.43
おっと、>>503に例のネタ、先を越された
508 :デフォルトの名無しさん2011/05/22(日) 15:36:55.32
なんども書いてるがcmd.exeっていうかWindowsのコマンドプロンプトでもUnicodeは使えるぞ。
UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。
UTF-8ではなくUTF-16になるから、#ifdefが必要になるだけで。
510 :デフォルトの名無しさん2011/05/22(日) 20:06:41.36
>>506 >>508
svnのmac portsのような対応をgitに望んでいるのか?
svnのmac portsのような対応をgitに望んでいるのか?
509 :デフォルトの名無しさん2011/05/22(日) 15:54:48.60
MS製品に依存してる連中がオレ様野郎ばっかというのがよく分かる。
Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。
Linux使ってる人が「VSSはLinuxで使えないから糞」なんて言わないからな。
別の意味では言ってるかも知れないが。
513 :デフォルトの名無しさん2011/05/22(日) 22:36:49.97
>>509
VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー
と、こんな風なレスを期待しているのか?
不毛じゃね?
VSSがいいといっても見向きもしないでしょ、その人達は
文句を言うときは実装と一緒
gitがいいという話を聞いてうっかり使ってしまい文句のみを垂れ流す、それがWindowsユーザー
と、こんな風なレスを期待しているのか?
不毛じゃね?
514 :デフォルトの名無しさん2011/05/22(日) 22:46:18.29
>>513
> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知
> VSSがいいといっても見向きもしないでしょ、その人達は
VSSが糞なのは周知
511 :デフォルトの名無しさん2011/05/22(日) 22:17:58.55
TortoiseCVSもTortoiseSVNも1つ落としてきてインスコするだけで使えるんだが
TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ
TortoiseGIT(笑)はそうじゃないんだよな
それを導入することによりよっぽど捗るとか利点がない限り
そんなまんどくせーものわざわざ手間かけてまでつかわねえよ
512 :デフォルトの名無しさん2011/05/22(日) 22:34:06.03
>>511
CVSとSVNのパフォーマンスとマージに満足なのですね?
CVSとSVNのマージはまんどくさくないのですね?
CVSとSVNのパフォーマンスとマージに満足なのですね?
CVSとSVNのマージはまんどくさくないのですね?
515 :デフォルトの名無しさん2011/05/23(月) 02:37:25.78
>>512
自分の使わない機能がいくら速かろうが関係ないの
おわかり?
自分の使わない機能がいくら速かろうが関係ないの
おわかり?
517 :デフォルトの名無しさん2011/05/23(月) 07:24:45.37
>>515
TortoiseCVS(笑) TortoiseSVN(笑)
TortoiseCVS(笑) TortoiseSVN(笑)
518 :デフォルトの名無しさん2011/05/23(月) 11:12:04.02
>>515
使わないんじゃなくて使い方がわからないんだろ
おわかり?
使わないんじゃなくて使い方がわからないんだろ
おわかり?
519 :デフォルトの名無しさん2011/05/23(月) 15:38:59.33
>>518
520 :デフォルトの名無しさん2011/05/23(月) 16:34:02.13
>>515
521 :デフォルトの名無しさん2011/05/23(月) 18:52:26.43
>>515
526 :デフォルトの名無しさん2011/05/24(火) 02:08:17.45
>>517
?
?
524 :デフォルトの名無しさん2011/05/23(月) 23:22:47.09
dropboxとかねーわ
525 :デフォルトの名無しさん2011/05/23(月) 23:33:47.28
>>524
もっと良い奴あるの?
もっと良い奴あるの?
527 :デフォルトの名無しさん2011/05/25(水) 00:03:05.80
>>525
SugarSync
SugarSync
528 :デフォルトの名無しさん2011/05/25(水) 00:15:54.04
>>527
どこら辺がいいの?
どこら辺がいいの?
530 :デフォルトの名無しさん2011/05/25(水) 19:27:34.81
いや、もちろん違いは知ってるんだけど、SugarSync のメリットがよく分からん
532 :デフォルトの名無しさん2011/07/16(土) 22:33:02.35
533 :デフォルトの名無しさん2011/07/17(日) 06:34:06.08
>>532
http://code.google.com/p/support/wiki/GitFAQ
> Is there a size limit on git repositories?
>
> For all source control systems, there is a 4GiB repository size limit. For git, we are starting with a push size limit of 500 MiB.
> If you try to push a pack over 500 MiB, your push will fail. We hope to lift this limit.
http://code.google.com/p/support/wiki/GitFAQ
> Is there a size limit on git repositories?
>
> For all source control systems, there is a 4GiB repository size limit. For git, we are starting with a push size limit of 500 MiB.
> If you try to push a pack over 500 MiB, your push will fail. We hope to lift this limit.
539 :デフォルトの名無しさん2011/07/25(月) 20:37:19.91
>>532
サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。
サーバのオプションどうなってるんだろうね。
sf.jpはrebaseできないの知らなくてすげー困ったんだけど。
535 :デフォルトの名無しさん2011/07/25(月) 19:55:07.99
Windows上にあるエロ画像とかエロ動画とか日記とかが雑多に保存してあるホームディレクトリを
まるっとバージョン管理するには何使ったらいいの
まるっとバージョン管理するには何使ったらいいの
556 :デフォルトの名無しさん2011/08/24(水) 15:54:04.86
>>535
NILFS
NILFS
536 :デフォルトの名無しさん2011/07/25(月) 20:10:57.22
dropBox
537 :デフォルトの名無しさん2011/07/25(月) 20:23:18.86
テキストとそれ以外はバージョン管理のシステムを分けたほうが良い?
538 :デフォルトの名無しさん2011/07/25(月) 20:35:40.84
>>536
え?dropboxってバージョン管理できたの?別スレで
ttp://d.hatena.ne.jp/shibamu/20101014/p1
見て阿呆かと思ったけど意味があったのか…
>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。
え?dropboxってバージョン管理できたの?別スレで
ttp://d.hatena.ne.jp/shibamu/20101014/p1
見て阿呆かと思ったけど意味があったのか…
>>537
同期して管理する必要が無いんだったら分けた方が良い、かも。
無関係なもの一緒くたにすると重くなりがちなので。
540 :デフォルトの名無しさん2011/07/25(月) 20:45:00.76
>>538
俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?
バージョン管理は別途ツールを使ってるよ
俺もソースツリーのバックアップを dropbox に置いてるけど、何か問題あるのか?
バージョン管理は別途ツールを使ってるよ
541 :デフォルトの名無しさん2011/07/25(月) 20:51:32.69
>>540
>>538はバックアップじゃねーぞ
>>538はバックアップじゃねーぞ
542 :デフォルトの名無しさん2011/07/25(月) 20:59:01.78
>>541
dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?
dropbox のディレクトリは単なるローカルのディレクトリでしょ
ビルドしてオブジェクトファイルが更新されたらバックグラウンドで
アップロードが走るのが嫌とか、そういう話?
544 :5382011/07/25(月) 21:44:02.08
>>540-542
ごめん俺drop boxのこと全く知らないし興味もないしスレ違いなので忘れて。
ごめん俺drop boxのこと全く知らないし興味もないしスレ違いなので忘れて。
545 :デフォルトの名無しさん2011/07/25(月) 21:50:02.80
最良のバックアップは配布だ。トモダチにコピーして回る。
で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。
で、どんな得ろ画像だ? JSと熟女と太めは歓迎なので俺とトモダチになれ。
547 :デフォルトの名無しさん2011/07/26(火) 00:04:51.49
dropboxならファイル単位で履歴管理できるしシェアもできる。
ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。
ソースの管理には向かないが、画像の管理にはそこそこ便利。
で、ソースのバックアップをdropboxに置くくらいなら、リポジトリを置いてしまうのも手。
548 :デフォルトの名無しさん2011/08/19(金) 23:24:45.47
gitで複数のブランチそれぞれに個別の未コミットのファイルを残したまま
ブランチを渡り歩くことってできる?
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。
diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。
ブランチを渡り歩くことってできる?
イメージとしてはbazaarで複数ブランチを同時にいじってて放置したまま
ブランチ間をcdで移動するみたいな。
diffとかはファイルとしての実体は不要でいいんだけど
gitは未コミット分をかかえたままになるのがちょっと困ってる。
いちいちstashとか嘘commitとかするのは
その判別含めて自動化できないと面倒で…。
552 :デフォルトの名無しさん2011/08/19(金) 23:50:55.94
>>548
ブランチの数だけcloneしたら?
ブランチの数だけcloneしたら?
553 :5482011/08/19(金) 23:57:29.95
>>552
自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。
ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない(というか人気のない?)使い方なのかな。
自分も一旦はそう考えたんだけど、それだと結局bazaarと同じ運用になって、共有リポジトリ使えない分だけ損してるような…。
ツリーは1つ、というのが気に入ってbazaarからgitに移行しようかと試してるんだけど
標準ではサポートされない(というか人気のない?)使い方なのかな。
550 :5482011/08/19(金) 23:40:47.88
少し調べてみたけれど、
Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの?
Mercurial の Shelve って git の stash と完全に同等に見えるけれど、そうでもないの?
551 :デフォルトの名無しさん2011/08/19(金) 23:45:29.57
TortoiseHgにあったShelve Changesは
ファイルごとに退避ができてstashより便利だなーって思った覚えが。
ファイルごとに退避ができてstashより便利だなーって思った覚えが。
554 :5482011/08/20(土) 02:26:16.94
濱野さんの本にはこう書いてある。
あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味(意図)が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。
ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に(まだ)合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2〜3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。
あとから追いやすくなるのでコミットは意味ごとに独立させるべき、
意味(意図)が同じコミットはあとからまとめるのもよい、
ローカルリポジトリは意味ごとにrebaseなどで改竄もむしろ推奨。
ということは、ブランチも意味ごとに直交させて切るべきだと思うんだけど
そーするとなぜ未コミット分がブランチをまたいで受け継がれるんだろう。
ブランチをまたぐ際にstashとか破棄前提の嘘commitが必要ってのは
単に実装が思想に(まだ)合致できてないってことなんだろうか。
日常的に使ってるとブランチは常に2〜3個必要になるし、
瞬間的には 4個とかにもなるんだけど、みんな困ってないのかな。
555 :デフォルトの名無しさん2011/08/20(土) 04:18:26.06
Shelve Changesも実は嘘コミットだと思えば気分が楽になるんじゃね?
いやShelve Changesがどんなものか知らんけど。
いやShelve Changesがどんなものか知らんけど。
557 :デフォルトの名無しさん2011/08/24(水) 21:49:54.87
たくさんのリポジトリを一気にPull(Fetch)できるGUIのツールって無いかな
GitやHgのリポジトリ一つずつ更新していくの面倒
いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし
GitやHgのリポジトリ一つずつ更新していくの面倒
いや、サブディレクトリにあるリポジトリでfetchをする
スクリプト書けばいいのかもしれないけれども、GUIの方が良いし
558 :デフォルトの名無しさん2011/08/25(木) 01:08:57.32
>>557
俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ
俺はそんなのシェル一行ですませるけど、GUIのツールがほしいなら作れよ
561 :デフォルトの名無しさん2011/08/27(土) 19:55:47.01
Bazaar日本語ファイル名の問題がないらしいので手を出してみたが
GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。
GUIの既定値が自分の使い方とあっていなかった。
コマンド入力で補助しないと行けない。
Mercurialは自分と合っていそう。
rebase, transplant, splitを使って少しだけ内容の違うブランチを
双方で変更する場合に対応できる。
今までsubversionでリビジョンの範囲をマージする方法でやってきたが
履歴改変にはまりそうだ。
562 :デフォルトの名無しさん2011/08/30(火) 18:05:51.79
会社で開発メンバーが増える事になり、バージョン管理システムを使えとのお達しがでた。
条件は以下の通り
・NASでソースは管理する。(購入済み)
・サーバーレスで動くもの
調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか?
上の条件に合致すれば 分散だろうが集中だろうが関係無いらしい。
条件は以下の通り
・NASでソースは管理する。(購入済み)
・サーバーレスで動くもの
調べた感じでSubVersionしか無いんじゃないかと思ったんだけど、他におすすめありますか?
上の条件に合致すれば 分散だろうが集中だろうが関係無いらしい。
570 :デフォルトの名無しさん2011/08/30(火) 23:54:03.63
>>562
SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。
SCMが全くわかってないなぁ、お前んとこの上司わ。
多分その上司は、そのNASがエクスプローラのWindowsネットワークに見えてないと
怒り出すんだろうな、きっと。
593 :デフォルトの名無しさん2011/09/04(日) 22:10:42.07
>>562
うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。
うちは Bazaar で共有リポジトリを共有フォルダ上において
push/pull あるいはmergeしてるから、NASを使っているのと
ほぼ同じ構成だな。
563 :デフォルトの名無しさん2011/08/30(火) 18:14:12.96
いやどれでもファイルベースのリボジトリ操作はできるだろうけど、
いろいろ無茶じゃないか……?
そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。
いろいろ無茶じゃないか……?
そのNASで複数の接続先から同時に同じファイルに排他ロックをかけようとして
ちゃんと動くか程度は確認したほうがいい。
ネットワークファイルシステム越しのロックがかからないようなら
サーバー建てるなり個人リポジトリとマージ用を分けるなり考えたほうがいい。
564 :デフォルトの名無しさん2011/08/30(火) 18:17:49.45
NASじゃ無理だろ
誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい
誰かのマシンでサーバを動かしてリポジトリはNASに置けばいい
566 :デフォルトの名無しさん2011/08/30(火) 18:33:06.19
いや、それこそsvnならファイルベースアクセスであってもロックファイルを作るぐらいのことはしてる。
だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。
問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。
だから一台のマシン上で複数プロセスから同時にコミットしても壊れない。
問題はネットワーク越しにそれをやると、ロックファイルを作ったつもりになって相手への反映が遅れるとか
NFSの制限でロック取れなくてもエラーが帰ってこないとか、なんか起きそうなことだ。
567 :デフォルトの名無しさん2011/08/30(火) 21:38:17.30
個人毎にリポジトリをもって、マスターのリポジトリへの反映は申請制とか
568 :デフォルトの名無しさん2011/08/30(火) 22:00:58.98
確かVSSはサーバーレスで動いたような……
569 :デフォルトの名無しさん2011/08/30(火) 22:33:14.62
分散型なら置くだけだからファイルコピーができる状況ならファイル置ける
576 :5622011/09/01(木) 17:17:03.76
>>568
VSSは使いにくいって上司がいってr
>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い?
必要無いなら保存先がNASってだけでいけそうかなぁと
もう文句言いまくるくせに自分では絶対しない人なんで
マンドクセ('A`) ヴァー
VSSは使いにくいって上司がいってr
>>569
分散型ってマスターの場所にサーバー入れて管理みたいな図を見たんだけど必要無い?
必要無いなら保存先がNASってだけでいけそうかなぁと
もう文句言いまくるくせに自分では絶対しない人なんで
マンドクセ('A`) ヴァー
579 :デフォルトの名無しさん2011/09/01(木) 18:22:06.68
>>576
保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。
保存先がNFSならいけたんだが、単なるNASだと無理。
あきらめろ。
571 :デフォルトの名無しさん2011/08/30(火) 23:58:32.02
ちなみに、オレんとこの会社では牛NASを殻割りしてdebian突っ込んで、
そこでapache+subversionを動かしてるから、
・NASでソースは管理する。(購入済み)
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。
しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?
そこでapache+subversionを動かしてるから、
・NASでソースは管理する。(購入済み)
という条件は満たしてるし、ソースの管理に必要なのはそのNASだけだから
・サーバーレスで動くもの
という条件も確かに満たしてはいる。
しかし当たり前のことだが、エクスプローラでは見えない。
つか、わかってないやつには見えないように設置する。これ、重要じゃね?
575 :5622011/09/01(木) 17:15:34.40
>>570
エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ
>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし
エクスプローラで見えてないとキチンと運用されているか俺がわからんとか言うタイプ
>>571
NAS(LS-WVL) を殻割りしてサーバー入れる手を考えてたんだけど、
「保証受けれなくなるし、もう半分ぐらい移行したから無理」とか言われるし
572 :デフォルトの名無しさん2011/08/31(水) 01:28:58.70
562の条件だとエクスプローラで見えなくても良さそうだが、
リポジトリを直接覗いて何が入ってるかわからん!なんて言われるレベルだとどうしようもないな
リポジトリを直接覗いて何が入ってるかわからん!なんて言われるレベルだとどうしようもないな
573 :デフォルトの名無しさん2011/08/31(水) 09:45:03.18
何も考えず独りよがりの思い込みでNASを買ってくる時点で、
どうしようもないレベルという条件は既に満たしてしまっている気がするが...。
どうしようもないレベルという条件は既に満たしてしまっている気がするが...。
574 :5622011/09/01(木) 17:08:25.56
みんなレスサンクス。
SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ
NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A`)
んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。
SCMについては俺もしっかり理解できてなくて勉強しながらやってるから勘弁してくれ
NASへのファイルの同時書き込みとかの問題は言ったんだけど
「今時のNASでそんなのあるわけないだろ、自宅で使ってるがそんな事起きたことが無い」
とか言われてナシのつぶてだった ('A`)
んで、別のサーバ動かしてリポジトリをNASに置く件については
「サーバーとNASが同時稼動前提とか何考えてるんだ」らしい。
578 :デフォルトの名無しさん2011/09/01(木) 17:57:08.96
>>574
自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。
自宅用途でそもそも同時書き込みが発生するかよ。
本当にファイルに排他制御がかかるかテストさせてくれないのであれば
個人リポジトリを分けて、マージ担当を置いたほうがいいな。
577 :デフォルトの名無しさん2011/09/01(木) 17:34:23.24
まあ、やってみなよ。リポジトリが壊れても知らんけど
いざとなったら日付フォルダで…
いざとなったら日付フォルダで…
580 :デフォルトの名無しさん2011/09/01(木) 18:26:56.25
どんなたいそうなNAS導入したのかと思ってググったら、それ15,000円位のゴミじゃん
業務でそんなの使うの?
サーバアプリ動かせるちゃんとしたの導入すれば?
業務でそんなの使うの?
サーバアプリ動かせるちゃんとしたの導入すれば?
581 :デフォルトの名無しさん2011/09/01(木) 20:18:22.50
まあ分散型なら自分とこのリポジトリが生き残っている可能性があるか…
583 :デフォルトの名無しさん2011/09/02(金) 02:05:35.26
たしかにGitでロック競合しておかしくなったとしても
なんとかなっちゃいそうだよな
なんとかなっちゃいそうだよな
587 :デフォルトの名無しさん2011/09/02(金) 08:37:09.09
分散型とか理解出来なさそうだ
592 :デフォルトの名無しさん2011/09/04(日) 21:57:37.98
>>587
そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。
そんなときこそ Bazaar ですよ。
分散型が理解できないアホには集中型として、理解できる人には分散型として使える。
594 :5622011/09/05(月) 13:51:32.54
>>592
のやり方が一番幸せになれるんじゃないかと思った。
まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある?
リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz
のやり方が一番幸せになれるんじゃないかと思った。
まだ自分がバージョン管理システムについて勉強中なんで
具体的な実現方法は見えてないんだけど、基礎的なものを勉強できる資料でおすすめって何かある?
リポジトリとかブランチとかさっぱりな初心者でも分かる資料・・・ orz
596 :デフォルトの名無しさん2011/09/05(月) 14:26:55.34
>>594
書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです
書籍・ドキュメント・実績豊富なGit・Mercurialを素直に使いましょう
まず近場の本屋に行きましょう
Bazaarが選択肢に入らないことは明かです
588 :デフォルトの名無しさん2011/09/02(金) 08:52:00.66
今まで鯖も立てずによく業務がこなせたなとある意味感心する
595 :5622011/09/05(月) 13:54:16.56
>>588
今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが8回。
全部自分が対応してなんとか復旧 orz
今までは自分が全部のソース管理をしてたんだよね。
でも今年の中頃から打ち合わせだとかで不在が多くなって
例の上司が「俺がソース管理をしてやろう」ってなってからデグレが8回。
全部自分が対応してなんとか復旧 orz
599 :デフォルトの名無しさん2011/09/05(月) 15:59:53.41
>>595
>今までは自分が全部のソース管理をしてたんだよね。
どうやってたのよ?
で、上司が管理したらなぜデグるのか、原因はわかってる?
バージョン管理システムは管理を楽にしてくれるし、 変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。
>今までは自分が全部のソース管理をしてたんだよね。
どうやってたのよ?
で、上司が管理したらなぜデグるのか、原因はわかってる?
バージョン管理システムは管理を楽にしてくれるし、 変なことできにくくしたり、
変なことしても復旧が容易だったりするけど、それでも変なソースをコミットして
混乱に陥るってことが皆無というわけじゃないよ。
603 :5622011/09/05(月) 19:02:18.38
>>599
今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。
修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新
上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ
今まではPG一覧の資料作って、修正する際は申請してもらって修正中フォルダへ移動
PG一覧へ修正者の記載。
修正が終わった段階で修正中フォルダからメインフォルダへ移動→PG一覧に更新日を修正状況を更新
上司がデグらせたのはこの辺の管理を全くせずに勝手にフォルダ移動OKにしたところ。
あとPG一覧も修正せずにいたからこうなった感じ
604 :デフォルトの名無しさん2011/09/05(月) 20:05:34.11
>>603
その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。
その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。
その運用がちゃんとできているなら、ツール入れればだいぶ省力化できると思う。
その上司じゃどうしようもないから、早めに管理システム入れたほうがいい。
605 :デフォルトの名無しさん2011/09/05(月) 20:11:31.83
>>603
Tracとかredmineを検討したほうがいいんじゃない?鯖いるけどw
Tracとかredmineを検討したほうがいいんじゃない?鯖いるけどw
607 :デフォルトの名無しさん2011/09/05(月) 23:55:40.10
>>603
うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。
うげぇ。そのPG一覧はExcelってオチか。
それはマズイ。
614 :5622011/09/06(火) 18:10:44.18
>>604
上司がやってなかったところがシステム化されるので大丈夫かなと思います。
>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。
鯖は無しでいいやつがいいです・・・・orz
上司がやってなかったところがシステム化されるので大丈夫かなと思います。
>>605
まだどのバージョン管理システムを使うか検討段階なんで
どういうものがあるかも含めて教えてもらえると助かります。
鯖は無しでいいやつがいいです・・・・orz
615 :デフォルトの名無しさん2011/09/06(火) 19:30:58.94
>>614
各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。
各ホストファイル共有ベースでやってるならなおのことDVCSがいいね。
616 :デフォルトの名無しさん2011/09/07(水) 00:08:14.87
>>614
聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。
とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。
聞いてる感じだとMercurialが無難そう。GUIクライアントもこなれてるし。
日本語ファイル名をつかうなら、個人的にはBazaarを推したいけど。
とりあえず、HgInitでぐぐって出てきたページを読んでみるといいよ。
オリジナルは英文だけど和訳もあるはず。
589 :デフォルトの名無しさん2011/09/02(金) 20:20:34.83
QNAP TurboNAS の CPUがそこそこ上位の奴 (Mervell ARM じゃなくて、Intel ATOMの) なら、
Subversion が動くようだ。(ipkg で導入できるっぽい)
http://www.google.co.jp/search?q=QNAP+Subversion
Mercurial, Git, Bazaar, TFS については知らん。
Python と gcc と mod_wsgi が用意されているようなので、Mercurial は動きそうな気もする。
http://www.google.co.jp/search?q=QNAP+Mercurial
Subversion が動くようだ。(ipkg で導入できるっぽい)
http://www.google.co.jp/search?q=QNAP+Subversion
Mercurial, Git, Bazaar, TFS については知らん。
Python と gcc と mod_wsgi が用意されているようなので、Mercurial は動きそうな気もする。
http://www.google.co.jp/search?q=QNAP+Mercurial
591 :デフォルトの名無しさん2011/09/02(金) 22:28:53.51
>>589 *nix系NASならbootする途中でのっとっちまえばなんでもありじゃん
gccのクロスコンパイラなんて簡単にできるんだしw
gccのクロスコンパイラなんて簡単にできるんだしw
600 :デフォルトの名無しさん2011/09/05(月) 17:44:12.82
分散型を選んで統合マネージャー型のワークフローで運用すればいいんじゃね
ttp://progit.org/book/ja/ch5-1.html#id103
どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う
ttp://progit.org/book/ja/ch5-1.html#id103
どう運用するかが肝でどのツールを選ぶかはたいした問題じゃないと思う
609 :デフォルトの名無しさん2011/09/06(火) 12:10:54.34
各モジュールに担当が決まっているような職場で、オプソ界隈のVCSがどれくらい効果的に使えるかねぇ?
…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600
…とか茶々入れてもしょうがないな。DVCSにして、マネージャ級だけがプッシュできるリポジトリを作るに一票。
>>600
601 :デフォルトの名無しさん2011/09/05(月) 17:56:40.55
なぁ、将来にわたって考えると数人月以上もコストがかかるやり方をやり始めるより、
5〜20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか
5〜20万出して(まともなサーバ or プログラムが実行できるNAS)(+UPS)を買った方が断然良くないか
606 :デフォルトの名無しさん2011/09/05(月) 23:17:15.66
鯖立ち上げまで一発でインストールしてくれる
そんな夢のようなツールないですかね
そんな夢のようなツールないですかね
610 :デフォルトの名無しさん2011/09/06(火) 17:12:20.61
画像ファイルをリポジトリに入れてるんだけど、色を変えただけでファイルサイズが同じだと
変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。
これって常識?
変更を認識してくれなくて酷い目にあった。
試してみたら
bzr : NG
git : NG
hg : OK
svn : OK
って感じだった。
これって常識?
617 :デフォルトの名無しさん2011/09/07(水) 00:32:56.06
>>610
>git : NG
これは信じ難いなぁ
>git : NG
これは信じ難いなぁ
618 :デフォルトの名無しさん2011/09/07(水) 11:29:43.76
>>610
同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。
同じサイズのバイナリファイルということで
dd if=/dev/urandom of=file count=1
で試してみたけど再現しないな。何かやり方を間違っているだけでは。
620 :デフォルトの名無しさん2011/09/07(水) 13:46:36.72
>>610
gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。
gitとbzrとsvnで確認してみた。
同サイズでタイムスタンプが同じだと、確かにgitとbzrはNGだった。svnはOK。
同サイズでタイムスタンプが異なるとgit、bzr、svnの全部がOKだった。
650 :6332011/09/07(水) 20:01:27.36
>>641
マジで?これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね?
>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。
ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。
BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。
マジで?これは恥ずかしい。
でもGitとBazaarはハッシュ取ってるよね?
>>642
そうは言っても、>>620 に書いてないMercurialも含めて、そういう挙動をしてるからなあ。
ちなみにタイムスタンプって言ってるのは、最後にコミットした時点のタイムスタンプじゃなくて、
ローカルで最初に変更チェックした時のタイムスタンプね。
BazaarとMercurialについては、一回ファイルの変更チェックしたら、サイズかタイムスタンプが変わらない限り再チェックされないようになってるように見える。
Gitは今手元にないから分からん。
613 :デフォルトの名無しさん2011/09/06(火) 18:04:07.75
>610
VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。
VCSによっては、タイムスタンプもサイズも同じなら中身まではチェックしないってのはある。
タイムスタンプが変わってるのにサイズが同じってだけで変更無し扱いになるってのはちょっと考えにくい。
619 :デフォルトの名無しさん2011/09/07(水) 12:15:08.63
ある程度以上の大きさのファイルは index に含まれなく、ファイル全体比較もしないんじゃないかな?
(一部だけ比較してるとか)
(一部だけ比較してるとか)
622 :デフォルトの名無しさん2011/09/07(水) 13:55:41.41
バイナリーは特別扱いだろ
623 :デフォルトの名無しさん2011/09/07(水) 16:18:44.38
>>622
それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ?
それは、バイナリファイルの場合は特別にタイムスタンプによって何か処理するということ?
624 :デフォルトの名無しさん2011/09/07(水) 16:37:24.24
まずバイナリの定義を述べてもらおうか
625 :デフォルトの名無しさん2011/09/07(水) 16:47:33.27
>>624
そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね?
そのVCSでテキストレベルのdiffが取れないのがバイナリの定義じゃね?
626 :デフォルトの名無しさん2011/09/07(水) 16:52:46.13
>>624
gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの?
gitとかsvnはバイナリファイルかどうかを判断してんだけど、知らないの?
627 :デフォルトの名無しさん2011/09/07(水) 17:29:05.52
>>624
mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ
mercurialだとNULバイト(0x00)が存在するものをバイナリファイルとして扱っているよ
628 :デフォルトの名無しさん2011/09/07(水) 17:30:24.65
gitのこと全然知らないんだけど、軽くググったところによると、「同サイズで同じexifを持ってれば同じとみなす」
とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。
とかいうことかも。
ファイルそのものの属性としてのタイムスタンプを見てるとは信じがたい。
629 :デフォルトの名無しさん2011/09/07(水) 17:35:55.51
気になるならテキストモードでやればいいだけ
それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ?)
この手の質疑応答は10年ぐらいから嫌という程みてきたわw
それが専用プラグインなんかを突っ込む(Excelなんかはそうやるだろ?)
この手の質疑応答は10年ぐらいから嫌という程みてきたわw
661 :デフォルトの名無しさん2011/09/08(木) 14:01:54.84
>>629
> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの?何か別の物と勘違いしてない?
今回の問題は「(フォーマット不明の)画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ?
GitやMercurialのFAQに書いてたりするのかな?
> この手の質疑応答は10年ぐらいから嫌という程みてきたわ
そうなの?何か別の物と勘違いしてない?
今回の問題は「(フォーマット不明の)画像ファイルをSCMで扱うとき、ファイルの日付と
サイズが同じ場合、内容が異なっていてもSCMによっては同一のものと認識する」だよ?
GitやMercurialのFAQに書いてたりするのかな?
630 :6292011/09/07(水) 17:40:21.02
×この手の質疑応答は10年ぐらいから嫌という程みてきたわw
○この手の質疑応答は10年以上前から嫌という程みてきたわw
要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事
○この手の質疑応答は10年以上前から嫌という程みてきたわw
要は該当するファイル群に対して強制的にハッシュを取るようにすればいいだけの事
632 :デフォルトの名無しさん2011/09/07(水) 17:48:52.87
>>630
何いってんの
何いってんの
631 :6202011/09/07(水) 17:45:28.75
gitとbzrとsvnで確認したのはWindows7上でした。
テキスト・バイナリ同じ結果となりました。
Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。
テキスト・バイナリ同じ結果となりました。
Linuxでは、ctimeを任意に変更することができなかったので
同じタイムスタンプのデータは作成できませんでした。
gitでは、chmod(ctime更新)したらそのテキストはmodifiedに
なりadd&commitできましたので、ctimeで判断しているように思えます。
667 :デフォルトの名無しさん2011/09/08(木) 17:42:49.51
>>620
OKってどういうこと?
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね?
>>631
gitはパーミッションも管理対象だからじゃね?
OKってどういうこと?
svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
「変更なし」になるんだけど。
変更を検知できないんならNGじゃね?
>>631
gitはパーミッションも管理対象だからじゃね?
668 :デフォルトの名無しさん2011/09/08(木) 17:53:14.49
>>667
> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。
まじか
svn使えねー
> svnってバイナリファイルはタイムスタンプ同じなら中身見ずに(つまりサイズが同じだろうが異なろうが)
> 「変更なし」になるんだけど。
まじか
svn使えねー
676 :デフォルトの名無しさん2011/09/09(金) 18:59:34.46
svnはこれだな。
http://stackoverflow.com/questions/4730452/why-does-subversion-fail-to-flag-a-modified-microsoft-excel-spreadsheet-file
ttp://feather.cocolog-nifty.com/weblog/2010/12/excelbazaartort.html
を読む限りでは、
svnは>>667の通りで、
bzrは>>650っぽいけど、初めの状態からタイムスタンプが変わらない限りは
svnと同様ファイルサイズ等のチェックはしない…らしい。
svnで試してみたがやはり変更は検出されない。>>610>>620は何か勘違いしてる。
>>668
bzr/gitでも試したがタイムスタンプ一緒だと変更検知できないよ。
http://stackoverflow.com/questions/4730452/why-does-subversion-fail-to-flag-a-modified-microsoft-excel-spreadsheet-file
ttp://feather.cocolog-nifty.com/weblog/2010/12/excelbazaartort.html
を読む限りでは、
svnは>>667の通りで、
bzrは>>650っぽいけど、初めの状態からタイムスタンプが変わらない限りは
svnと同様ファイルサイズ等のチェックはしない…らしい。
svnで試してみたがやはり変更は検出されない。>>610>>620は何か勘違いしてる。
>>668
bzr/gitでも試したがタイムスタンプ一緒だと変更検知できないよ。
633 :デフォルトの名無しさん2011/09/07(水) 18:03:41.17
バイナリだろうがテキストだろうがハッシュはとるでしょ。
ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。
毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。
ファイルサイズの大小ならともかく、テキストかバイナリかでその辺の挙動を変える意味はないし。
毎回全ファイルのハッシュ計算するわけにもいかないし、タイムスタンプとサイズが一致してたらとりあえず
未変更とみなすっていうのはそれなりに妥当な落としどころだと思う。
636 :デフォルトの名無しさん2011/09/07(水) 18:17:49.92
>>633
何いってんの
どのSCMのコード見ての発言なの
何いってんの
どのSCMのコード見ての発言なの
638 :デフォルトの名無しさん2011/09/07(水) 18:23:46.11
>>633
毎回全ファイルのタイムスタンプとサイズをやりとりするの?
毎回全ファイルのタイムスタンプとサイズをやりとりするの?
641 :デフォルトの名無しさん2011/09/07(水) 18:49:21.28
>>633
取らない物が殆ど
仕様をちゃんと読め
取らない物が殆ど
仕様をちゃんと読め
635 :デフォルトの名無しさん2011/09/07(水) 18:17:45.90
とりあえず差分は無理だからな。丸ごと保存することになる場合が多い
639 :デフォルトの名無しさん2011/09/07(水) 18:26:01.40
>>635
svnは内部的にはバイナリファイルも差分で持ってるぜ
svnは内部的にはバイナリファイルも差分で持ってるぜ
637 :デフォルトの名無しさん2011/09/07(水) 18:21:51.64
ネットワーク越しのクライアント使う場合も、ローカルファイルのメタデータ送ってるって事か?
642 :デフォルトの名無しさん2011/09/07(水) 18:52:36.71
タイムスタンプがどうとか言ってる奴はバージョン管理を何だと思ってるの?w
643 :デフォルトの名無しさん2011/09/07(水) 19:03:14.53
画像なんかのバイナリをバージョン管理に含める人がまだいるんだなぁ。
こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。
こういう人達はDBに沢山の画像をつっこむ以上に愚かだわ。
645 :デフォルトの名無しさん2011/09/07(水) 19:09:17.24
古い常識つーか今も常識でしょ。
リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。
リポが肥大して後で消そうにも消せない問題は未だ健在(出来る物も有るけどね)。
そんな拡張によるニッチな要求を満たした例を上げて「今はバイナリも突っ込むのが常識」なんて言われても説得力がないわい。
647 :デフォルトの名無しさん2011/09/07(水) 19:49:21.44
自分の常識があらゆる場合において普遍と思ってる奴は結構多いからな
648 :デフォルトの名無しさん2011/09/07(水) 19:52:05.38
ゲーム開発でバージョン管理にバイナリ突っ込む?えっ?
定期的にスナップショットをとるだけだろ…
あぁ同人か…
定期的にスナップショットをとるだけだろ…
あぁ同人か…
655 :デフォルトの名無しさん2011/09/07(水) 21:31:19.43
>>648
画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。
以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。
画像データの内容とプログラムの仕様が一致していないとマズいから、
コードとデータを一緒くたにSubversionで管理してるよ。
以前までコードとデータを別々に管理してたけど、
コードだけ更新してデータを更新しないとか、逆のこととかが頻発するんだよね。
特に納期直前にそんな事あったら目も当てられん。
656 :デフォルトの名無しさん2011/09/07(水) 21:48:56.84
>>655
ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない
ディレクトリ、ファイル単位で別々のリビジョンをチェックアウトできるSubversionでは、
その要件は満たさない
657 :デフォルトの名無しさん2011/09/08(木) 00:24:05.54
>>656
そうなのかな。よく理解できてないけど。
そうなのかな。よく理解できてないけど。
659 :デフォルトの名無しさん2011/09/08(木) 11:28:05.50
>>655
うむ。一番楽だ。重いけどな。
>>656
わかりやすく説明してちょ。
うむ。一番楽だ。重いけどな。
>>656
わかりやすく説明してちょ。
651 :デフォルトの名無しさん2011/09/07(水) 20:08:37.60
見えるとかわからんとか言うぐらいなら一々レスするなって・・・・
652 :6202011/09/07(水) 20:19:42.68
git statusやbzr statusでmodifiedってならないだけならいいんだけど・・・
私の環境(Win7pro 32bit、bzr2.4.0、git 1.7.6 mysgit)だと、
ファイル名を指定してcommit(gitの場合はaddでファイル名指定後)も、
できないのが困る。
この現象が、私だけなのか、誰かWindowsでの動作を試してみてくれませんか?
私の環境(Win7pro 32bit、bzr2.4.0、git 1.7.6 mysgit)だと、
ファイル名を指定してcommit(gitの場合はaddでファイル名指定後)も、
できないのが困る。
この現象が、私だけなのか、誰かWindowsでの動作を試してみてくれませんか?
662 :デフォルトの名無しさん2011/09/08(木) 14:06:41.17
>>652
bzrで--unchangedつけてもダメ?
bzrで--unchangedつけてもダメ?
665 :6202011/09/08(木) 16:46:29.90
>>662
bzrで--unchangedをつけて、試しましたがコミットは増えましたが、
変更が取り込まれませんでした。
再度Linux(Debian etch on VMware Player)とgit(1.5.6.5)で実験しました。
VMware Playerのフォルダ共有の機能でWindows上のフォルダを共有。
そこにディレクトリを作成してgitレポジトリを作成。
ファイルを追加してコミットした後、ファイルのサイズが変わらないようにファイルの内容を変更。
touchでファイルの存在するディレクトリとファイルのタイムスタンプを変更前のタイムスタンプに戻す。
VMwareのファイル共有ディレクトリだと、touchでctimeも変更できました。
この状態でgit statusをしても、変更がないと認識されました。add&commitもできませんでした。
bzrで--unchangedをつけて、試しましたがコミットは増えましたが、
変更が取り込まれませんでした。
再度Linux(Debian etch on VMware Player)とgit(1.5.6.5)で実験しました。
VMware Playerのフォルダ共有の機能でWindows上のフォルダを共有。
そこにディレクトリを作成してgitレポジトリを作成。
ファイルを追加してコミットした後、ファイルのサイズが変わらないようにファイルの内容を変更。
touchでファイルの存在するディレクトリとファイルのタイムスタンプを変更前のタイムスタンプに戻す。
VMwareのファイル共有ディレクトリだと、touchでctimeも変更できました。
この状態でgit statusをしても、変更がないと認識されました。add&commitもできませんでした。
666 :デフォルトの名無しさん2011/09/08(木) 17:03:17.59
>>665
gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる?
gitの場合、.gitattributes ファイルに
*.foo binary
と書いとけば、拡張子.fooファイルはバイナリだと扱われる
これで試すとどうなる?
653 :デフォルトの名無しさん2011/09/07(水) 20:27:04.66
要件上、画像の編集履歴を取りたい+過去版を参照・取得したい
というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。
ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。
ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。
というのが必須なら、やはりVCSに突っ込むのがベターな選択だと思うよ。
ただその場合は、プログラムコードの管理をメインに開発されたVCSよりは、
Adobe Version Cueのような画像・映像データのアセット管理をメインに据えた
製品を選定するのが良いと思う。……というかそれは板違いの話になるな。
ちなみにウチは帳票定義用のバイナリーファイルをSVNに突っ込んでる。
Excelとか、Wordとか、PDFとか。
654 :デフォルトの名無しさん2011/09/07(水) 21:22:09.87
バイナリを入れないってのは、機械生成できる実行形式みたいな
のを入れないっていう意味だろ女子高生
のを入れないっていう意味だろ女子高生
660 :デフォルトの名無しさん2011/09/08(木) 12:45:06.80
わざと一部だけ違うバージョンのファイルを混ぜてバージョンが一致してないとか言い出す揚げ足取り
663 :デフォルトの名無しさん2011/09/08(木) 14:40:48.36
少なくともgitはファイルスタンプなんて見てない
画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る
画像はexifを見てるんだろうが、気に入らなきゃ自分で設定出来る
664 :デフォルトの名無しさん2011/09/08(木) 15:36:12.91
てか、プログラムで扱う画像ファイルにはexifなんか無いのが多いのでは?
669 :デフォルトの名無しさん2011/09/08(木) 18:17:29.09
GitについてLinux(Debian Lanny)とMac OS X(10.6)で確認したら
サイズとctimeが同じでも、中身が違えば変更検知されたのだが
サイズとctimeが同じでも、中身が違えば変更検知されたのだが
671 :6202011/09/08(木) 18:37:47.23
>>667
私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。
>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。
私の環境のTortoiseSVNだと、変更したファイルをクリックして状態を
観ると変更ありになり、コミット可能でした。
>>669
ファイルのみのctimeが同じな場合は、変更が検知されましたが、
その親ディレクトリのctimeを一致させた場合は、だめでしたので、
665ではそのように記述しました。
672 :デフォルトの名無しさん2011/09/08(木) 18:50:46.18
>>671
.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ
.git/ がある親ディレクトリまで含めて、全てのディレクトリとファイルの
ctimeを同じにしたけど、中身が違えば変更が検出されたぞ
どうなってんだ
670 :デフォルトの名無しさん2011/09/08(木) 18:28:23.18
中身を見るなんて無駄な処理は要らない
タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい
タイムスタンプを変えないなんてわざとそうているのなら
運用する側が工夫すればよい
677 :デフォルトの名無しさん2011/09/09(金) 19:11:14.55
サイズの同じ画像ファイルsample1.png, sample2.png を用意して、
こんな感じのシェルスクリプトを書いて実行してみた
---------------------------------------------
#!/bin/sh
mkdir dir
cd dir
echo "*.png binary" > .gitattributes
git init
touch .gitattributes
touch ../dir
cp ../sample1.png a.png
git add a.png
cp ../sample2.png a.png
cd ..
---------------------------------------------
実行は一瞬で終わるので、dir と dir/a.png と .gitattributes は全部同じタイムスタンプになった(statで確認)
で、git status してみたら変更が検知されたよ
こんな感じのシェルスクリプトを書いて実行してみた
---------------------------------------------
#!/bin/sh
mkdir dir
cd dir
echo "*.png binary" > .gitattributes
git init
touch .gitattributes
touch ../dir
cp ../sample1.png a.png
git add a.png
cp ../sample2.png a.png
cd ..
---------------------------------------------
実行は一瞬で終わるので、dir と dir/a.png と .gitattributes は全部同じタイムスタンプになった(statで確認)
で、git status してみたら変更が検知されたよ
679 :デフォルトの名無しさん2011/09/10(土) 08:47:32.42
つか file stat関係って、cifs とローカルで微妙に仕様が違ったりするんじゃないっけ?
680 :デフォルトの名無しさん2011/09/11(日) 04:38:09.42
毎回全ファイルの内容をチェックしてたらステータスの確認に時間がかかるから仕方ない。
変更したファイルはtouchすればいい。
変更したファイルはtouchすればいい。
681 :デフォルトの名無しさん2011/09/11(日) 13:38:57.77
>>680
だなー。内容変えたらタイムスタンプも変えておけってこった
だなー。内容変えたらタイムスタンプも変えておけってこった
683 :デフォルトの名無しさん2011/09/12(月) 11:18:01.38
変更したファイルをtouchすれば良いだけの話なのに
ぐだぐだと粘着してた奴が
svnも検知できないと分かったとたんパッタリ消えたのが笑えるwww
ぐだぐだと粘着してた奴が
svnも検知できないと分かったとたんパッタリ消えたのが笑えるwww
687 :デフォルトの名無しさん2011/10/01(土) 10:17:37.48
最近sf.netよりgithubなプロジェクト多いな
sf.netだと古くて動かないこと多いし
でも日本語ファイル名あったらsvnの方がいいのになんでgitなんだろ
sf.netだと古くて動かないこと多いし
でも日本語ファイル名あったらsvnの方がいいのになんでgitなんだろ
689 :デフォルトの名無しさん2011/10/01(土) 11:31:56.07
とにかくSourceForgeが使い辛いことにみんなが気づいてきたのが一因にあると思う
用途によってはsvnのほうが良いとしても、githubとSourceForgeには超えられない壁がある
用途によってはsvnのほうが良いとしても、githubとSourceForgeには超えられない壁がある
692 :デフォルトの名無しさん2011/10/01(土) 15:37:43.92
まあリヌース君が「svnは肥溜めの糞の中にあるサナダ虫の糞の中にある細菌の糞」って言っちゃったからなあ
693 :デフォルトの名無しさん2011/10/01(土) 18:32:06.16
少なくともフリーのバージョン管理システムと言えばCVS、と考えていた時代にリビジョンの概念を導入したSVNの功績は認められるべきだと思うんだが。糞とまで言われるのは使っていた自分としては哀しすぎる。
695 :デフォルトの名無しさん2011/10/01(土) 21:33:32.16
>>693
振り回され過ぎ。ほぼ完璧にUnicode対応
出来てるのは今でもsvnだけだし、
業務に使うのにこれほど信頼できるものも他にない。
リポジトリがネットワーク的に近ければ十分現役。
OSSのリポジトリは遠いからDVCSの速度が必須というだけ。1コミットに数分とかありえないだろ
振り回され過ぎ。ほぼ完璧にUnicode対応
出来てるのは今でもsvnだけだし、
業務に使うのにこれほど信頼できるものも他にない。
リポジトリがネットワーク的に近ければ十分現役。
OSSのリポジトリは遠いからDVCSの速度が必須というだけ。1コミットに数分とかありえないだろ
697 :デフォルトの名無しさん2011/10/01(土) 22:44:13.89
>>695
ローカルで履歴弄り放題のgitもいいもんだぞ
Windowsだと未だにsvn一択なのが悲しいが・・・
ローカルで履歴弄り放題のgitもいいもんだぞ
Windowsだと未だにsvn一択なのが悲しいが・・・
698 :デフォルトの名無しさん2011/10/02(日) 08:15:31.39
>>695
> 振り回され過ぎ。ほぼ完璧にUnicode対応
> 出来てるのは今でもsvnだけだし、
> 業務に使うのにこれほど信頼できるものも他にない。
バックアップが無くて全てパー
サーバがクラックされて全てパー
> 振り回され過ぎ。ほぼ完璧にUnicode対応
> 出来てるのは今でもsvnだけだし、
> 業務に使うのにこれほど信頼できるものも他にない。
バックアップが無くて全てパー
サーバがクラックされて全てパー
699 :デフォルトの名無しさん2011/10/02(日) 09:58:33.94
>>698
そう煽るなら上2行は引用しないのが適切
そう煽るなら上2行は引用しないのが適切
694 :デフォルトの名無しさん2011/10/01(土) 21:23:49.83
svnもよいものだったと思うよ。いまだに使われてるのもその証だし
CVSよりイケてるのがほぼsvnだけだった、て時代が長かったてのもあるけど
まあ、より使いやすい(と誰かが考える)ものに変わってくのはなんでも同じ
svnがそこにあって、それが気に入らなかったからLinusもgitつくったわけだし
よくもわるくも、svnがなければhgもbzrも育ってないと思う
だからsvnはよくやった、いままでごくろうさん、て感じかね
俺としては、ファイルシステムレベルでVCSをブチこんでくれないかな、
と前から思ってるんだけど。そういう構想とかないのかなあ
CVSよりイケてるのがほぼsvnだけだった、て時代が長かったてのもあるけど
まあ、より使いやすい(と誰かが考える)ものに変わってくのはなんでも同じ
svnがそこにあって、それが気に入らなかったからLinusもgitつくったわけだし
よくもわるくも、svnがなければhgもbzrも育ってないと思う
だからsvnはよくやった、いままでごくろうさん、て感じかね
俺としては、ファイルシステムレベルでVCSをブチこんでくれないかな、
と前から思ってるんだけど。そういう構想とかないのかなあ
696 :デフォルトの名無しさん2011/10/01(土) 21:57:58.42
>>694
Lionだと、全てのドキュメントが自動セーブ&自動バージョニングされるらしいぞ、知らんけど
Lionだと、全てのドキュメントが自動セーブ&自動バージョニングされるらしいぞ、知らんけど