アカウント名:
パスワード:
うーんと、スレッドのごくごく初めのところしかカバーしてないようですね。
BCの主張 [iu.edu]は、
ひとつだけ離れたところにある、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
論争の(ごく大雑把な)概要 (スコア:4, 参考になる)
LM: BitKeeper(BK)のレポジトリをCVSレポジトリに即時反映するようになったので、ちょっと使ってみて
Ben Collins: 要するにBKをカーネル開発のデフォルトにして、他の選択肢(CSSCベースのBitBucketとか)を潰そうってことでしょ。それだとカーネル開発のリソースに100%アクセスできないヒトが出るんだよ。市場支配だ。
H.Peter Anvin: 帯域が限界に近いんだから、よそのサーバでやってくれ。
LM: サーバなんかすぐ用意できるよ。金は出すから連絡してくれ。重要なのはCVSレポジト
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]には笑えました。