アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
CVSもSubversionも子供のおもちゃ (スコア:0, 参考になる)
コード管理とかやったことない人にとりあえず体験させるには手軽だと思うが。
目にした管理ツールは手に入る限りかたっぱしから運用して試したけど、
優れた順に上げれば、Bitkeeper, Arch, Darcs, 番外編で quilt+なんらかのパッチ送信手段
だった。(Archはあの命名規則でいろいろトラブル起こすんで、実際にはDarcsとquilt使ってますが)
結局バージョン管理システムなんて現場では役に立たなくて、
真面目に管理したければパッチ管理システム使うしか無いという結論に達しました。
使い方次第だとおもいますがねえ (スコア:2, すばらしい洞察)
自分で視野を狭くしている印象がありますね
CVSだって十分使えますよ
CVSでなきゃいけない理由はないとおもいますが
Re:CVSもSubversionも子供のおもちゃ (スコア:1)
純粋にその優先順位を聞きたいですね。評価しているところはなんなのでしょうか。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
着目点は、
1. 気軽にブランチが作れて実験でき、気軽になかったことにできて黒歴史も残らない
2. 黒歴史なのが判明するのは後になってからだから、ブランチ作成時にマスターに記録が残らず、
マージを決意した時に初めて残る。
3. 同じ理由で、黒歴史作成中にも黒歴史内の履歴は残る必要がある。
4. トライアングルマージが容易
で合格点だったのが前に上げた奴。
monotoneはリポジトリにトラブルがあった時に救出できないっぽくて残念。
で、quiltはそれ自体では同期機能がなくて一手間増えるから番外行き。
Archの方がトライアングルマージを助けてくれる機能があるし、どこからマージしたが覚えてくれるからDarcsより上。
BitKeeperはなんだったかなー。とにかく快適だったのだけ覚えてるか…変態的命名規則が無いからArchより上かな?
唯一お試しできた商用ツールだったのが有利だっただけかも。
あの名前ルールと~/にミラーを作ってからクローン作成というルールさえなければ、
Archがあれば他は全部ゴミみたいな勢いだった。
Re:CVSもSubversionも子供のおもちゃ (スコア:3, 興味深い)
これは結構重要ですよね。
ブランチって、実験のために作るのだけど、実際に実験してみてうまくいかなかったのにずっと残ってしまうのは精神的にもよくないです。
あとは、うちの会社では、Subversionですけど、新人君が、テストコードの中に秘密のパスワードを書いたりしてしまって、履歴から消すために、dump/filter/restoreという手間を経なければ消せなかったのはきつかったです。
Re:CVSもSubversionも子供のおもちゃ (スコア:2, すばらしい洞察)
まるっきり逆では?
実験してみて、それが駄目だったことが、はっきり記録に残った方が遥かにいいでしょう。
もし記録から完全消去してしまったら、また誰か別の人が同じ実験で時間を浪費することになるかもしれないし。
逆に、無駄だと思ったことが、諸条件が変わるとあとで有効に変わることがありますよ。
Re:CVSもSubversionも子供のおもちゃ (スコア:1, 興味深い)
>もし記録から完全消去してしまったら、また誰か別の人が同じ実験で時間を浪費することになるかもしれないし。
>逆に、無駄だと思ったことが、諸条件が変わるとあとで有効に変わることがありますよ。
他人の失敗を自分が踏まないで済んだ轍として、晒したり責めるより感謝する文化があるか?
諸条件が変わってあとで有効になった時、その時なぜ見つけないんだと責めない文化があるか?
(複数人では)そういう条件が存在する場合にだけ失敗を残しておく事が有意義になるんですね、
自分一人の記録記録だったら、誰も失敗が残ってる事など気にせず全然問題ないだろうけど。
Re:CVSもSubversionも子供のおもちゃ (スコア:1, すばらしい洞察)
その条件が存在しない「チーム」なんてものは、元々破綻してる。
少なくとも生産性は低いだろうな。
たがいに疑心暗鬼モードで仕事してるんだから。
コーディング規約と監視で縛り上げてるチームはみんなそうだ。「最低の生産性」しか持ってない。
Re:CVSもSubversionも子供のおもちゃ (スコア:1, 参考になる)
いや、そんなことないですよ。
コーディング規約はないよりあった方がいいですし、コードレビューも、品質を確実に上昇させます。
ただ、もし、レビュー作業が、他人をあげつらうための監視...っていう雰囲気になったら、たしかに生産性は落ちるし、それはレビュー自体がうまくいってないことを意味するでしょうね。
うまくいかなかった試験実装をリポジトリにコミットすることをためらうような雰囲気がある開発プロジェクトは、既に破綻していう点も同感です。
Re:CVSもSubversionも子供のおもちゃ (スコア:0)
(1)現場というのは、主にFLOSSの分散開放開発環境のことを指しているのではないか?ソフトウェアのインハウスでのコンピューティングを現場というが、今回その意味かは明示的でなく、確認するのがよさそうだ。SCMの評価は、常に分散開放開発環境を想定しているかどうかでこの評価は変わってくると私は想定している。
(2)自分の黒歴史(というか各人の試行錯誤の記録)がツリー上に残ってしまうことが、後から記録を追いかける時に障壁となると想定しており。その障壁があることが、子供のおもちゃ扱いをしている理由である。と理解していいか?もっと他に根本的な欠点があるから「子供のおもちゃ」扱いをしているのではないのか?他人の状況に依存するようなら、あまり「子供のおもちゃ」扱いをするとも思えないが。
Re:CVSもSubversionも子供のおもちゃ (スコア:0)
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, おもしろおかしい)
ウウッ!