バージョン管理システムについて語るスレ8

1 名前：デフォルトの名無しさん mailto:sage [2011/01/20(木) 12:26:04 ] バージョン管理システムについて語りましょう ●過去スレ バージョン管理システムについて語るスレ pc11.2ch.net/test/read.cgi/tech/1193332500/ バージョン管理システムについて語るスレ2 pc11.2ch.net/test/read.cgi/tech/1215520728/ バージョン管理システムについて語るスレ3 pc12.2ch.net/test/read.cgi/tech/1228366972/ バージョン管理システムについて語るスレ4 pc12.2ch.net/test/read.cgi/tech/1242918130/ バージョン管理システムについて語るスレ5 pc12.2ch.net/test/read.cgi/tech/1255241922/ バージョン管理システムについて語るスレ6 hibari.2ch.net/test/read.cgi/tech/1270640436/ バージョン管理システムについて語るスレ7 hibari.2ch.net/test/read.cgi/tech/1283780922/ 388 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:18:50.31 ] bitbucketとlaunchpadなら断然bitbucket githubの方がもっといいけど 389 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:19:07.53 ] 分散だと日本語環境はbzrが独占状態なのよねぇ。 他は何をやってんのやら。 390 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:23:24.89 ] >>389 > 分散だと日本語環境はbzrが独占状態なのよねぇ。 > 他は何をやってんのやら。 「Windowsのファイルシステムの」日本語環境でしょ。 Windows上で日本語ファイル名を使わなければ、Git、Mercurialでは何も不自由しないけど。 391 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:27:13.00 ] そうはいっても ○○支社向け.docとか ○○部長月間予定.xlsとか いう日本語ファイル名って結構使うからねぇ 392 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:31:50.17 ] >>391 リポジトリを分ければ良い。 そういうファイルがあるところだけsvnにすれば良い。 svnはリポジトリを一ヶ所にするというのが一般的のようだが、 別に一ヶ所にする必要もない。 393 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:35:09.66 ] 運用ポリシーで複数の管理システムを使うのはちょっとね 後々の事を考えてシンプルにしないとさ 394 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:46:48.22 ] Windowsだけで使う分にはHgでも日本語ファイル問題ないだろ？ 395 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:48:38.19 ] >>394 CP932に無いUnicodeの文字も増えてきているからねえ・・・ 396 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 14:21:26.83 ] ○○支社向け.docとか○○部長月間予定.xlsとかは分散してる必要無いんじゃないか。 どうせマージ出来ないだろうから、むしろ分散してたら不都合な気がする。 そういうのはsvnでいいんじゃね。 397 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 14:50:19.02 ] >>396 Mercurialはロックを実装する気でいるぞ。 mercurial.selenic.com/wiki/LockExtension/NewDesign 398 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 15:39:09.50 ] >>397 分散型でlockとかｗｗｗ というのは釣りですが、それでワークフローがうまく回るなら良いですね。 特に仕事でアジャイル（）とかだと分単位で作業が入り乱れるだろうから、 バグトラッカとかでやりとりするよりもスムーズかも知れない。 399 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 15:39:15.31 ] かといって、1プロジェクトに関わる設計書とかが単一の管理から外れるのも困る。 結局のところ、運用でごまかせって感じになっているのがなぁ。 誰だよ1バイト圏意外に住んでいるやつは。 400 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:10:18.30 ] >>396 中央リポジトリ関係無く好きに各ローカルリポジトリにプッシュ/プル出来るから分散のメリットは大ありだよ 人間の相関と分散管理はすごく相性がいいから無駄なんていっちゃいかん 401 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:13:02.54 ] ×無駄なんて ○不都合だなんて 失敬 402 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:41:36.52 ] >>400 ワードとかエクセルのマージ作業はどうするの？ 403 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:43:59.18 ] それって別に分散かどうかは関係ないよね 404 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 16:49:45.42 ] >>403 マスターリポジトリにプッシュするまでもない物をとりあえず確認するために 個人のローカルリポジトリにアクセスしたりとか 個別相談受けて訂正する時にその人のローカル除いたりとか色々ある メッシュ網じゃないsvnなんかじゃこういうのは出来ないのさ 405 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 14:39:55.41 ] gitやhgが「Windowsでは」Unicode APIを使わずにバイト列でファイル名を扱うのはなんなんだ バイト列なら>>376の言うようにPythonが対応しようが解決できないよね、これ BazaarのようにUnicodeと決めているならUnicode APIに渡すときに変換なりするわけでしょ でもバイト列で扱う方針なら変換できないよね localeに応じて変換するのだろうか マルチバイトのファイル名のマルチプラットフォームの問題はそもそも解決できない問題なの？ 406 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:02:14.19 ] 根本的には、ファイルシステム毎に使える文字が違うんだから細かい差異まで吸収できるわけがない。 やろうと思えば主要ファイルシステムの動作をエミュレートできるようにしたうえで、addした時のファイルシステムを覚えておくことになるだろうし。 それとは別に、必要な変換をしてくれないのは単なる無理解と手抜き。 gitについてはLinux上で最高のパフォーマンスが出せれば後はどうでもいいという大義名分があるけど、hgは単に開発者が無理解なだけだろ。 (bzrの互換漢字を正規化してしまう問題も、そんなことをするファイルシステムが現存しない以上やり過ぎと言える) 407 名前：デフォルトの名無しさん mailto:sage [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の混在に慣れているが、これは日本の特殊事情 408 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:23:53.14 ] >>406 > hgは単に開発者が無理解なだけだろ。 無理解とは思えないが。 mercurial.selenic.com/wiki/EncodingStrategy cmd.exeとGUIアプリの扱いが違うというのは、このスレでは話題になっていなかったが。 bzrがcmd.exeでCP932の方が無理解だと思うが。 409 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:29:36.71 ] hgが叩かれる時のリンクじゃないかそれ cmd.exeでもW版APIを使えばokというのが周知されてないのも無理解の象徴だな 410 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:33:04.46 ] >>409 cmd.exeでwは使えない。 wprintf()がcp932とかcp1252の時にデータが欠損する。 411 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:35:38.99 ] >>409 bzrでお馴染みのpythonのコーデックエラーは、cmd.exeのことを考慮していない証拠。 412 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:37:30.80 ] 使えるっての。 libcではなく自分でAPI呼べよ 413 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 15:45:46.84 ] >>412 chcp 1252 して日本語混じりのをwprintfしたら何が出力される？ だったら、printfでバイト列で出力した方がマルチプラットフォームアプリとしては 正しいと思うが。 414 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:09:39.19 ] >>413 cmdでUnicode使わない背景には、cmdのフォントの設定によっては表示されない 恐れがあるからという理由があったはず。 まぁ、一番は単に他の部分のファイルのインタフェースと整合性を取るのが大変 だからだろうけど。 CLIでunicode使いたかったら cygwin + minitty が最強。 415 名前：414 mailto:sage [2011/05/01(日) 16:10:15.09 ] >>412 だった。 416 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:14:13.63 ] UnicodeじゃないからUnicode版API使えないと言いつつ、 得体の知れないバイト列をANSI版APIに流し込む矛盾。 417 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:15:14.84 ] >>412 出力って何のこと？diffとか？ 418 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 16:18:07.25 ] >>416 CP932と繁体字がASCIIと互換が無いから問題なのであって、 それ以外のコードページとLinuxでは、シングルバイト用のAPIで何ら問題が無い。 419 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:18:31.36 ] >>413 さすがPowerShell ISEさんに隙はなかった・・・ 420 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:21:34.79 ] >>419 Mercurialは--encodeオプションかHGENCODING環境変数で、UTF-8が指定できるから、 PowerShellでも問題ない。これが正しい多言語化。 421 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:23:30.72 ] --encodingだった。 --encodingmodeってのもある。 422 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 19:40:05.99 ] >>420 や、俺が言ってるのはコンソールとしてのpowershell_ise.exeのことね chcpコマンドがまともに機能するWin7標準のアプリ 従来の対話型コマンドが動作しないのが玉に瑕 423 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:00:58.60 ] >>422 PowerShell ISEってフルで言わないとだめなのか。 PowerShell ISEでMercurialでchcp 65001が最強。 424 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:09:01.55 ] >>423 うん、同意 425 名前：デフォルトの名無しさん mailto:sage [2011/05/01(日) 20:26:56.00 ] chcp 65001 をしたら、fopenがutf-8を受け付けるようになるの？ 426 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:10:01.43 ] >>313 そのwprintfはwcstombsしてるんだろ。 まずWriteConsoleWでUTF-16のまま無変換出力を試みる →エラーになったらコンソール以外にリダイレクトされてるから 保存用コード(ロケール使うのが正しいがオプションでUTF-8を提供してもいい)に変換して改めてWriteFile がWindowsでの正しいUnicode対応コンソールアプリの作り方。 427 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:10:24.54 ] >>413だった 428 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:29:52.71 ] >>426 Mercurialはファイル名とファイルの中身以外は内部UTF-8なんだからwcstombsを使う理由が無い。 mercurial.selenic.com/wiki/EncodingStrategy#Functions にある通り、fromlocal()、tolocal()、colwidth()という関数が用意されている。 429 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:35:44.01 ] >>428 すまん、アンカーミスなんだ。 元はcmd.exeでWが使える使えないの話の流れなんだ。hgの実際の実装は関係ないんだ。 430 名前：デフォルトの名無しさん mailto:sage [2011/05/02(月) 12:50:32.48 ] >>429 バージョン管理と何の関係があるの？ 431 名前：デフォルトの名無しさん mailto:sage [2011/05/04(水) 12:27:28.61 ] PowerShell ISEは旧来のコマンドプロンプトの諸問題を解決してくれて便利 シェルとして使いにくいのが悲しい点 432 名前：デフォルトの名無しさん mailto:sage [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 とかで出来たと思うんだけど。 433 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 18:30:32.51 ] 普通に考えたらdiff取るだけなのに毎回リモート見に行く必要があるsvnのほうが…… 434 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 19:17:16.19 ] SVN脳と言わざるをえないｗ 435 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 19:31:10.28 ] そうまでリモートに集約したいなら集中型のsvn使っとけば丁度良いよ 436 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 19:38:27.23 ] gitスレでも指摘されてるじゃないか 集中型じゃなくて分散型の思想について勉強してこいよ 437 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 19:39:28.24 ] ゲソなりく〜ん 438 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 20:03:09.13 ] >>432みたいに新しい環境に拒絶反応示して興奮してる人って、後で恥ずかしくなったりしないのかね？ 439 名前：デフォルトの名無しさん mailto:sage [2011/05/17(火) 20:05:44.30 ] 全成果プリントアウト(しかもシリアルプリンタで)がいいとおもうよ☆ 440 名前：デフォルトの名無しさん mailto:sage [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 442 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 01:42:52.29 ] >>440 bzrはできる。 443 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 02:05:27.82 ] もうさわんなよｗ タダの基地外なんだから。 444 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 02:07:36.82 ] bzr は遅くて泣けてくる・・・ 445 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 02:50:35.02 ] >>444 最近はそうでもないぞ。 といっても、Windows以外のユーザーが最新のbzrを使うにはソースから インストールするかFedoraかUbuntuの最新版を使わなきゃいけないけど。 446 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 08:46:27.06 ] ＞使っていたソフトの開発元が svn+trac からgithubに ＞変わってしまってかなり機能後退と分かりゲンナリです。 このソフトって何だろうね。 意図せずGitHubに移行しなきゃいけなくなってゲソナリってことみたいだけど、 そこまでイライラするぐらいなら古いバージョンでsvn+trac使うことは出来ないのかな？ 447 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 08:50:26.59 ] ＞酷い有様だな。 おまえの頭がな 448 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 09:23:18.91 ] 分散型がキモかったらsvnを使い続けていれば良い。 svnがキモくてcvsを使い続けているところもある。 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 も結構追いつきつつある(と思う)。 > あんまり日本語ファイル管理することもないんだけどね。 449 名前：デフォルトの名無しさん [2011/05/18(水) 11:36:09.86 ] >>433 svnはリモート見に行く必要は無いんだが何いってんの? 450 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 11:47:33.18 ] >>449 それは作業領域の話。 特定のリビジョン間のdiffを見る場合、リモートを見に行く必要がある。 451 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 12:03:07.87 ] svnの仕組みもしらないsvnﾏﾝｾｰがﾌｧﾋﾞｮｯてると聞いて 452 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 12:22:45.76 ] スレがずいぶんと酷い有様だな。 453 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 17:26:11.89 ] ということでsvk最強 454 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 18:58:53.50 ] >>445 いや、最近久し振りに使ったら遅くて泣けた・・・ 455 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 19:33:53.77 ] >>454 毎日使ってるけど、遅くて泣きたくなるのは、画像ファイルとかバイナリファイルを たくさんリポジトリに突っ込んじゃった場合だけ。 どんな状況で遅かった？手元のバージョンが良くてもサーバー側のバージョンが 悪かったりしない？ 456 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 19:35:04.65 ] >>455 launchpadの遅さは異常 457 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:00:36.69 ] >>456 試しにやってみたら、 bzr branch lp:mysql-server が 73771 リビジョンの ブランチに 16m37sec かかった。 速いとは言わないけど、別に1日たっても終わらないとかじゃないし、最初の 1回だけだし、十分実用的な速度だと思う。 github や bitbucket に mysql のミラーないかな？ 458 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:08:09.61 ] 24時間経過しても終わらない上にエラーで失敗したりするgit cvsimportとかと比べたら 16分とか一瞬だった 459 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:08:55.41 ] 無理すんなよw 460 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:14:56.64 ] >>457 Linuxカーネルは？ bitbucketじゃないところにhgのミラーはあるよ。 確かhgのポリシーにのっとって、バージョン毎にリポジトリが分かれていたから、 単純比較できないかもしれないけど。 461 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:16:19.31 ] time svn co 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 の方が速いんだろうけど、別に泣きたくなるほど遅くはないな。 462 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:21:40.34 ] Emacs も酷いね。 463 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:27:44.57 ] >>461 初回はどー考えてもsvn有利だろw 464 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 21:43:00.22 ] てか履歴1個だけじゃ他の分散型と比べられないよなー 465 名前：デフォルトの名無しさん mailto:sage [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月辺りにはなんか問題あったらしいけど、改善されたらしいね。 466 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 22:00:37.84 ] time の履歴が流れちゃったけど、 savannah から git で emacs を clone したら5分弱だった。emacsの場合はgitの方が4倍くらい速いな。 とりあえず、一晩たっても終わってないとかそういうのはなさそうだから、 実用上問題にはならないだろ。 467 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 22:02:22.21 ] bzrはやいなぁ hgから乗り換えるかな 468 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 22:39:21.80 ] bzrの遅さはpull, push, merge全部が遅いってことでしょ。 インターネット越しじゃなくて、イントラネットでも。 469 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 22:47:37.12 ] バージョン上がる度にbzrは早くなってるな 470 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 23:47:49.94 ] 俺もいつかは bzr が速いって言える様になるのかな・・ 471 名前：デフォルトの名無しさん mailto:sage [2011/05/18(水) 23:53:10.75 ] bzrはhgより早いし次はsvnとgitだな 472 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:29:13.45 ] と、bzr信者は何の根拠も無く申しております 473 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:32:44.03 ] hgはオワコン 474 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:35:21.89 ] と、bzr信者は何の根拠も無く申しております 475 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:37:37.15 ] 時代はgitとbzrの2強の時代へ 476 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:49:17.80 ] と、bzr信者は何の根拠も無く申しております 477 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:53:13.72 ] マジレスするとGitとhgだろうな。どっちも似てるんだけどね。 GitHub vs Google Codeか。Launchpadはいまいち人気無いよね。 478 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 00:54:05.80 ] gitは男の子。bzrは女の子。hgはハードゲイ。 479 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 01:05:32.02 ] github は本当に良く出来てるよね 必要な情報が無駄無く配置されていて使い勝手がとても良い 480 名前：デフォルトの名無しさん [2011/05/19(木) 02:24:14.68 ] gitはM$捨ててるからM$で遊んでる俺の選択肢にはなり得ない 481 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 08:05:41.81 ] >>461 githubのruby、trunk以外のブランチも入っているじゃん 482 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 08:10:45.02 ] >>480 code.google.com/p/msysgit/issues/detail?id=80#c77 repo.or.cz/w/git/mingw/4msysgit.git/shortlog/refs/heads/kb/unicode 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 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 08:17:10.66 ] gitもhgもutf-8に対応しているが、cmd.exe、MSysなど、MSの環境が糞なので、 まともに使えないってことだ。 484 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 11:17:07.01 ] >>481 うん、完全に同じ条件ではないとあとで気づいた。 だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と してはあながち的外れな比較でもないと思う。 まぁ、やりたかったことは、bzrとgitのどっちが速いかを調べることではなくて、 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。 本気で比較したかったらLAN上で帯域やレイテンシやパケロス率を制御した環境を 作れるはずだけど面倒なのでパス。 485 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 18:55:21.88 ] >>484 > 一部の人がbzrがクソ遅いと連呼しているから本当に実用に支障が出るくらい > 遅いのか調べたかっただけだから、emacsやMySQLレベルの大きさのプロジェクトでも > 一晩経って終わらないとかそういう事が無いことが確認できただけで満足。 launchpadにアカウントを持っている人が一部の人では？ Emacsはlaunchpadではないけど、github・bitbucketに比べてcloneが目に見えて遅いのは 普通の感覚だと思うが。 486 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 19:06:38.32 ] >>484 > だけど、gitでは操作がリポジトリ単位でbzrはブランチ単位というのは実際に特定の > ブランチにしか興味がない人のclone速度に影響するんだし、リアルなケースの1例と > してはあながち的外れな比較でもないと思う。 git・hgはリポジトリに全部のブランチを入れるかブランチ毎にリポジトリを分けるか、 柔軟性があるけど、bzrはブランチ単位でしかcloneできないんじゃないの？ githubのrubyはgit-svnを叩いているから、ブランチだらけの状態だと思うけど。 487 名前：デフォルトの名無しさん mailto:sage [2011/05/19(木) 19:31:26.64 ] launchpadは遅いというよりちょくちょく落ちてるのがなあ…… 488 名前：484 mailto:sage [2011/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に敵わないけど、遅いという印象を払拭するには インタフェース面でもできることがありそう。

---

---

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

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