5236 story BK->CVS (real time mirror) 5 ストーリー by Oliver 2003年03月13日 9時21分bk使えない人達にも救いの手を 部門より yosshy 曰く、 "ふと LKML を覗いてみたら、 掲題の投稿のタイトルを見つけて笑ってしまいました。 Linux カーネルの開発に使用されている商用リポジトリ管理ツール BitKeeper のオープンソースクローン BitBucket に続く新プロジェクトか？と思いきや、投稿者は BitKeeper の Larry McVoy 本人ではありませんか。 どうやら BitBucket の騒ぎからヒントを得たもののようですが、開発者達の意見は賛否両論。果してこの商用 v.s. オープンソース騒ぎの行く末は？"
頼むから (スコア:2, すばらしい洞察)
もうちょっと内容がわかるようにしてくれ。
論争の(ごく大雑把な)概要 (スコア:4, 参考になる)
LM： BitKeeper(BK)のレポジトリをCVSレポジトリに即時反映するようになったので、ちょっと使ってみて
Ben Collins： 要するにBKをカーネル開発のデフォルトにして、他の選択肢(CSSCベースのBitBucketとか)を潰そうってことでしょ。それだとカーネル開発のリソースに100%アクセスできないヒトが出るんだよ。市場支配だ。
H.Peter Anvin： 帯域が限界に近いんだから、よそのサーバでやってくれ。
LM： サーバなんかすぐ用意できるよ。金は出すから連絡してくれ。重要なのはCVSレポジトリがBitMover社の支配下にないってことだ。
Andreas Dilger： そんなに悪い方にばっかり考えるのは良くない。BKを使わないヒトはこれでハッピーになれるんだ。CSSC(とBitBucket)だってまた新しいBKのデータフォーマットに対応すればいいことだし。
H.Peter Anvin： でもCVSからBKへデータを戻すことはできないでしょ。それじゃあBitMoverの好き勝手と言う状況は変わらない。
Dana Lacoste： それってなんだかGPLの議論みたいだよ。LinusがBK使ってるんだからみんなBKに移行しようよ！
…Yada Yada…
という感じでしょうか。まあ後は互いの主張を言い合っているのかな。ちゃんと読んでないので間違いがあったらツッコんでください。
Re:論争の(ごく大雑把な)概要 (スコア:0)
個人的には、BK側の対応は、なかなか素早く適切で
好印象。
Re:論争の(ごく大雑把な)概要 (スコア:5, 参考になる)
うーんと、スレッドのごくごく初めのところしかカバーしてないようですね。
BCの主張 [iu.edu]は、
- BK->CVSによって作られるCVSリポジトリはオリジナルの情報を100%含まない。
- これはBKに依存せざるを得ない状況を作ろうとしているLM(もしくはBitMover)による、かなりマーケティングを意識したやり方だ。
というもので、それに続く発言では、- これまでのところBKはとても便利に使えてきた(0966 [iu.edu])。
- BKからメタデータをテキストとして引き出す機能は以前からあるし、今でも使える(1085 [iu.edu])。
- CVSがBKの情報を完全に扱えないのはBKの非ではない。引き出されたメタデータから元の情報をきちんと再構築することはやろうと思えばできるんだから(1150 [iu.edu])。
というような発言が続き、さらにLMが- 実際BK->CVSでやっているのは、元のBK内にある様々なブランチをCVSに合わせるために(できるだけうまく)シリアライズしている。
- そのために失われる情報も一応拾ってある。
とコメントした [iu.edu]のでBCも納得 [iu.edu]し、その後は変換の詳細についての技術的な質疑応答になってます。結局「LMさんBitMoverさん、いいものをありがとね！」で論争は一見落着という感じです。ひとつだけ離れたところにある、
- BKを使ってる今でこそパッチの情報がきちんと保存されるようになったけど、そもそもBK移行以前のCVS時代には、Linusによるパッチの手動マージの際におそらく現在の半分近くの情報が失われてたんだから、BK->CVS変換で10%の情報が失われたって、CVS時代よりはずっと恵まれてるんだよ。
という発言 [iu.edu]には笑えました。二元論？ (スコア:1)
どうして商用とオープンソース二元論の話に持っていくのでしょうか？不快感を感じました。
結果的には平和的に(?) [slashdot.jp]解決しそうなのでよかったですが…。