アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
CVSもSubversionも子供のおもちゃ (スコア:0, 参考になる)
コード管理とかやったことない人にとりあえず体験させるには手軽だと思うが。
目にした管理ツールは手に入る限りかたっぱしから運用して試したけど、
優れた順に上げれば、Bitkeeper, Arch, Darcs, 番外編で quilt+なんらかのパッチ送信手段
だった。(Archはあの命名規則でいろいろトラブル起こすんで、実際にはDarcsとquilt使ってますが)
結局バージョン管理システムなんて現場では役に立たなくて、
真面目に管理したければパッチ管理システム使うしか無いという結論に達しました。
Re:CVSもSubversionも子供のおもちゃ (スコア:0, 余計なもの)
自分が使いこなせないだけで役立たず認定ですか?
Re:CVSもSubversionも子供のおもちゃ (スコア:0)
現場で品質維持まで絡めて考えれば実際問題なにも管理した事になって無いんだよ。
少人数か、さもなければすべてのブランチが時間軸にそって一方向にしか進まないんであれば、
SVNでもCVSでも問題ない。
でも実際問題、複数のサブプロジェクトが同時進行で、
大量のプログラマが生み出す大量のコソコードをマージしつつ、後戻りも発生すると考えると、
SVNもCVSもマージ担当者がミスを犯さない事を前提にしないと運用無理。
例えば、複数のリビジョンに対するリバースパッチを当てた新しいリビジョンつくって、
それで本当に問題のアブプロジェクトは元に戻っていて、かつ他のパッチは元に戻っていない事をどうやって保証する?
Re:CVSもSubversionも子供のおもちゃ (スコア:4, すばらしい洞察)
プロジェクトの管理方法の責任をソースコード管理システムにしわ寄せしても
それは破綻するだけだと思うし、実際、そうなったという話に見える。
道具って使い方がまずいと混乱を招くだけ。適材適所を常に考えて使わないと
駄目だと思うよ。
Re:CVSもSubversionも子供のおもちゃ (スコア:4, すばらしい洞察)
Re:CVSもSubversionも子供のおもちゃ (スコア:0)
小規模単寿命プロジェクトしか無いならなんだって別にいいんだって…
サブシステムA,B,Cの相互作用により発生する問題を解決するサブプロジェクト
とかどうすんのさ?
Re:CVSもSubversionも子供のおもちゃ (スコア:4, 興味深い)
>サブシステムA,B,Cの相互作用により発生する問題を解決するサブプロジェクト
まず、それがサブシステムA,B,Cの設計ミスで、手戻りになることを認識する必要がある(ミスがあること自体は仕方がない)。その上でそこが解決するまで関連部分の開発を凍結すべき。そこは進めても手戻りになる確率が非常に高い。同様にマージが大量発生している部分は手戻りになる確率が高い。賽の河原の積木崩しは士気を削ぐ。わざわざメンバを死地に赴かせる事もなかろ?
コードや人やグループの「情報の局所性」を考えたらソース管理は教条的にはロック式が基本。でもそれじゃ例外的事態に対応できないのでマージがあると考えるのが安全だよ。それともバザール式で開発する?だとするなら同じ場所にいることは大してアドバンテージにならないけどね。
Re:CVSもSubversionも子供のおもちゃ (スコア:1)
できないのかな?
例えばfeature freezeってフェイズがあるとして、
API定義(Cならヘッダ、javaならinterface?)は変更禁止とか
定義と実装が混じってるコードだと難しいけど、インテリジェントになれば可能な気がする