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