バージョン管理システムについて語るスレ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/ 369 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 14:22:22.90 ] >>364 Windowsはutf-16 のAPIを提供しているのでそれを使えば問題ない。 どっちかっつーと、Mac OS X の方が、バージョン管理システムに限らず ファイルをアップロードするときとか、zipファイルの中身とかいろんな 場面に影響するので凶悪。 370 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 14:49:34.62 ] >>369 ファイル名の話してんのに何言ってんの？ 論点のすり替え乙 371 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:19:32.78 ] >>370 ファイル名の話だよ？ Windowsは10年以上昔(NT 4.0)からファイル名はUnicodeで扱っている。 Shift-JISなどでアクセスするAPIはレガシー用の互換APIで、基本的に使うべきではない。 372 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:23:47.02 ] 厳密に言えば NT 3.1 (93年) だけど、サーバー、ワークステーション向けを のぞいたらWinXP (01年) だから、10年以上ではないな。 373 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:24:17.13 ] いやだからファイル名の 話だろ？ 374 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:24:26.87 ] Mercurialは、pythonがクソでレガシーAPI使ってるのが癌なんだろ。 375 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:25:13.49 ] あ 最新レス見ずに書いちゃった 376 名前：デフォルトの名無しさん mailto:sage [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 に渡している。 377 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:31:31.57 ] >376 それがクソって言ってんの 378 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 16:34:02.13 ] >>377 えー、これがクソならどうしろと、、、 C#やJavaみたいにバイト列でファイルパスを指定するの禁止したらUnix系で すごく使いにくくなるんだけど。 Python の仕様は超現実的で、RubyやPerlよりもずっとWindowsで使いやすいと 思ってる。 379 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 17:11:59.63 ] というかそれならMercurialで問題になってるのは何なの 380 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:26:12.29 ] >>379 mercurial.selenic.com/wiki/EncodingStrategy 381 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:29:23.48 ] >>379 英語のwikiにはNTFSはUTF-16となっているが、実際は２バイトのバイト列。 UTF-16としては不正な値も格納される。 382 名前：デフォルトの名無しさん mailto:sage [2011/04/26(火) 18:33:09.11 ] NTFSがUTF-16とは書いていないか。 > kernel has a mix of byte-width and wide character APIs 383 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 10:45:25.11 ] Windowsシステムオンリー。日本語ファイル名あり。日本語ディレクトリあるかも。 Git、Mercurial、Bazaarから、上記の条件で考えた場合、分散型初心者が取っつき やすいのは日本語対応が進んでいるBazaarでしょうか？ 384 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:04:37.41 ] その条件ならシェル統合がまともに動くMercurialじゃないか 385 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:10:24.25 ] Bazaarは日本語対応進んでいないでしょ。 386 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:15:43.07 ] Windows onlyならhg、bzrのどちらでもいいと思う でかいファイルを扱うならhgかな 387 名前：デフォルトの名無しさん mailto:sage [2011/04/28(木) 11:16:05.67 ] 書籍の有無、Web上での情報量、CUI/GUIのメニューの日本語化を含めて日本語対応と言うべきであって、 Mercurialが一歩抜き出ていて、CUI/GUIのメニューは >>325 でGitも対応する方向だと言う認識だが。 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は早くなってるな

---

---

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

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