アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
CVSもSubversionも子供のおもちゃ (スコア:0, 参考になる)
コード管理とかやったことない人にとりあえず体験させるには手軽だと思うが。
目にした管理ツールは手に入る限りかたっぱしから運用して試したけど、
優れた順に上げれば、Bitkeeper, Arch, Darcs, 番外編で quilt+なんらかのパッチ送信手段
だった。(Archはあの命名規則でいろいろトラブル起こすんで、実際にはDarcsとquilt使ってますが)
結局バージョン管理システムなんて現場では役に立たなくて、
真面目に管理したければパッチ管理システム使うしか無いという結論に達しました。
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)自分の黒歴史(というか各人の試行錯誤の記録)がツリー上に残ってしまうことが、後から記録を追いかける時に障壁となると想定しており。その障壁があることが、子供のおもちゃ扱いをしている理由である。と理解していいか?もっと他に根本的な欠点があるから「子供のおもちゃ」扱いをしているのではないのか?他人の状況に依存するようなら、あまり「子供のおもちゃ」扱いをするとも思えないが。