アカウント名:
パスワード:
私の経験では、kernelほどsourceの大きい(file数、sizeの両面で)ものになると、patchを作って投げるという方法が破綻してしまいます。大量のpatchを効率よくmergeするのにBitKeeperを用いたわけですが、それによって楽になったのは実はLinusだけなのです。ほかの人はLinusが持っているBitKeeperのdepotを全く触らせてもらえません。その結果、Linus以外の人達は相変わらず手でほかの人からのpatchとmergeする作業をするはめになっています。自分たちはちっとも楽になっていません。Linusに対して反発が出る根源は、むしろここにあるのではないでしょうか?
FreeBSDの場合、version control systemとしては従来のcvsのほかに、perforce depotも利用しています(cvs repoへのcommitは直ちにperforce depotへ反映、5.0 DP1ではrelease作成にも用いた)。perforceを導入した最大の動機は、SMPngやKSEのように複雑な工程を要する作業の場合、project全体のbranchと作業者個人のbranchが分離できないと効率が上がらないことです。FreeBSDのpreforce depotでは、必要ならばcommitter(一部非committerを含む)がいくらでも勝手にbranchを切ることができます。cvsと違い、branchやintegrationが高速(branchを切る場合、src/sysなら30秒以下、cvsでは2-3分)なのも便利です。私はこれを触って以来、自前でcvs repoを持つのをやめてしまいました。
ある程度は速くなるかも知れませんが、決定打になるかどうかは分かりません。
最近のversion control systemは、depot-client間での無駄な転送を極力抑える工夫をしています。BitKeeperの場合はよく分かりませんが、perforceではほかのbranchからの差分をmergeする際、conflictが生じないfileはdepot内部で片付けてしまいます。conflictが生じたfileのみclientへ転送した上で修正するので、mergeの度に全てのfileを転送する必要はありません。
cvsを本当に高速化するなら、repoのDB化と合わせて、repo側で十分な処理をclientにやらせないようにする工夫も必要でしょう。
どこをどう読めばそうなるの?
bitkeeper導入でLinusは楽になったけど、Linus以外のkernel開発者(各種アーキテクチャへの移植や個々のデバイスドライバ等ということになるのかな?)は最新のリポジトリ(はcvsの用語だけど、他の単語思いつかないので)へアクセスできないので、他の人の変更を手動でmergeするしかない。これではLinus以外の人の工数は減らない、と言ってるだけだと思いますが?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
新しいものは使うべき (スコア:2, 興味深い)
それによってパッチを投げ易くなれば,今存在するhackerよりも,もっとスゲー奴が現れる可能性は,高くなると思うからです.
# パッチを投げ易くなったというのが前提.知らないけど.
自分が使いたくないからヤダ.だけではなくて,他に目を向けられたら,もっと発展していくのかなあ.とか.
Linusしか便利にならないBitKeeper (スコア:5, 参考になる)
私の経験では、kernelほどsourceの大きい(file数、sizeの両面で)ものになると、patchを作って投げるという方法が破綻してしまいます。大量のpatchを効率よくmergeするのにBitKeeperを用いたわけですが、それによって楽になったのは実はLinusだけなのです。ほかの人はLinusが持っているBitKeeperのdepotを全く触らせてもらえません。その結果、Linus以外の人達は相変わらず手でほかの人からのpatchとmergeする作業をするはめになっています。自分たちはちっとも楽になっていません。Linusに対して反発が出る根源は、むしろここにあるのではないでしょうか?
FreeBSDの場合、version control systemとしては従来のcvsのほかに、perforce depotも利用しています(cvs repoへのcommitは直ちにperforce depotへ反映、5.0 DP1ではrelease作成にも用いた)。perforceを導入した最大の動機は、SMPngやKSEのように複雑な工程を要する作業の場合、project全体のbranchと作業者個人のbranchが分離できないと効率が上がらないことです。FreeBSDのpreforce depotでは、必要ならばcommitter(一部非committerを含む)がいくらでも勝手にbranchを切ることができます。cvsと違い、branchやintegrationが高速(branchを切る場合、src/sysなら30秒以下、cvsでは2-3分)なのも便利です。私はこれを触って以来、自前でcvs repoを持つのをやめてしまいました。
Re:Linusしか便利にならないBitKeeper (スコア:1, すばらしい洞察)
ダウト!
Re:Linusしか便利にならないBitKeeper (スコア:0)
Re:Linusしか便利にならないBitKeeper (スコア:0)
Re:Linusしか便利にならないBitKeeper (スコア:1)
CVS も repository を DB に入れたら速くなるかな。
Re:Linusしか便利にならないBitKeeper (スコア:2, 参考になる)
ある程度は速くなるかも知れませんが、決定打になるかどうかは分かりません。
最近のversion control systemは、depot-client間での無駄な転送を極力抑える工夫をしています。BitKeeperの場合はよく分かりませんが、perforceではほかのbranchからの差分をmergeする際、conflictが生じないfileはdepot内部で片付けてしまいます。conflictが生じたfileのみclientへ転送した上で修正するので、mergeの度に全てのfileを転送する必要はありません。
cvsを本当に高速化するなら、repoのDB化と合わせて、repo側で十分な処理をclientにやらせないようにする工夫も必要でしょう。
Re:Linusしか便利にならないBitKeeper (スコア:0)
だから彼が何を使おうが自由なのでは?
それに、カーネルのrevisionが上がったら、ソースは
公開されるのでしょ?
Re:Linusしか便利にならないBitKeeper (スコア:0)
Re:Linusしか便利にならないBitKeeper (スコア:2, 参考になる)
それからlinux-2.5の開発の履歴 [bkbits.net]を見てください。
旧来のパッチによる更新のほかにリポジトリ間の同期による変更をやっているのを見ることができると思います。
Re:Linusしか便利にならないBitKeeper (スコア:0)
brake-handle氏の指摘は、bitkeeperが改善に寄与していないのではなく、
bitkeeperが状況を悪くしたというように読めますが。
Re:Linusしか便利にならないBitKeeper (スコア:1)
どこをどう読めばそうなるの?
bitkeeper導入でLinusは楽になったけど、Linus以外のkernel開発者(各種アーキテクチャへの移植や個々のデバイスドライバ等ということになるのかな?)は最新のリポジトリ(はcvsの用語だけど、他の単語思いつかないので)へアクセスできないので、他の人の変更を手動でmergeするしかない。これではLinus以外の人の工数は減らない、と言ってるだけだと思いますが?
Re:Linusしか便利にならないBitKeeper (スコア:0)
すまぬ・・・。
Re:Linusしか便利にならないBitKeeper (スコア:0)
仮にその指摘があたっていたとしても、それでいいじゃん
いままでのlinusの過剰な負荷が軽減されればね
Perforce (スコア:0)