アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
CVSもSubversionも子供のおもちゃ (スコア:0, 参考になる)
コード管理とかやったことない人にとりあえず体験させるには手軽だと思うが。
目にした管理ツールは手に入る限りかたっぱしから運用して試したけど、
優れた順に上げれば、Bitkeeper, Arch, Darcs, 番外編で quilt+なんらかのパッチ送信手段
だった。(Archはあの命名規則でいろいろトラブル起こすんで、実際にはDarcsとquilt使ってますが)
結局バージョン管理システムなんて現場では役に立たなくて、
真面目に管理したければパッチ管理システム使うしか無いという結論に達しました。
Re:CVSもSubversionも子供のおもちゃ (スコア:0, 余計なもの)
自分が使いこなせないだけで役立たず認定ですか?
Re:CVSもSubversionも子供のおもちゃ (スコア:4, 興味深い)
今あるレポジトリをもとに、まだコンセンサスがとれていないアイデアを試してみたいと思ったことはありませんか?
そしてそのアイデアを試すためには一度のコミットで済まないほど大きな変更が必要な場合はどうしますか?
その都度ブランチしたり、ローカルにバージョン管理システムを用意しているなら
分散レポジトリに対応したバージョン管理システムを検討してみてはいかがでしょう。
上記のような問題はおよそ解決されると思います。
慣れない場合も運用次第で単一レポジトリの場合と同じように扱えますし。
#元ACの考えとは多少違うとは思いますが。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
(ここまで見た範囲で)誰も
SVKに言及してないのは何故だ?
それこそ「使えない」からなのか?
(いや、私も使ったことが無いのでOKかNGかは判らないんだが)
一応説明をしておくとSVNを階層バージョン管理ツール化しちゃう一種のプロキシリポジトリを作れるツール。
ところでひげぽん氏は
「どこからどこまでがマージされたのか?というメタ情報がSubversionにはないのですよね」
といってるが、
それこそSVNの「プロパティ」で管理すればいいんじゃないかな?
マージ情報を入れとくプロパティを決めて、それに書くっていう。
もっともクライアントがそういう処理をやってくれないと
ならない(というか旨みが無い)が。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 参考になる)
http://subversion.tigris.org/roadmap.html [tigris.org] によると
>1.5
>Merge tracking: tracking of merge history (see info)
となってるんでもう少し待てば Subversion 本体で使えるようになるんじゃないかと思います。
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?)は変更禁止とか
定義と実装が混じってるコードだと難しいけど、インテリジェントになれば可能な気がする
Re:CVSもSubversionも子供のおもちゃ (スコア:1, おもしろおかしい)
ウウッ!