アカウント名:
パスワード:
Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...
...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重
checkoutされたfileをlockすることのデメリットとしては、CVS tutorial [sra.co.jp]のOHP [sra.co.jp]「衝突回避の一つのアイデア [sra.co.jp]」に挙がっています。一番つらいのは、fileを見るだけでもcheckoutするはめになること。見るだけならup-to-dateなものが必要とは限らないため、lockはするだけ無駄(どうせ変更は加えられない)です。
複数fileのlock(CVSの場合commitの禁止)はCVSROOT/availでしょうね。最も、きちんとmoduleを管理していないと使いものになりませんが、これは何を使っても同じか...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
コードフィックスと言う概念 (スコア:1)
確かにVSS使ってますが、いつまでたっても機能追加できてしまうエンドレス管理システムだったりする。
結局、MSの製品のバージョンって「見栄えの違い」以外認識できない気がする今日この頃です。
Windowsだって、結局いろんな機能拡張が出てきてWindows95でも、
WindowsXPでも似たような事ができてしまっ
職業としてのプログラマ
Visual SourceSafe 6.0を見てみたけど (スコア:2, 興味深い)
Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...
...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
というか、たしか、デフォ設定がロック型管理になっているというだけだったような記憶が。
ただ、共同所有について開眼(笑)していない人、つまり
そのメリットを知らず、デメリット(というか憶測にもとづく恐怖?)ばかりを信じて
いる人々にとっては、ロックがかからない管理方法ってのは
本能的(笑)に怖くなるようですね。
コードを書いたひとが後々のデバッグのセキニン(笑)まで負う、
などという呑気なモデルを未だに採用してるトコロには、
VSSは似合いのツールなんじゃないかな :-P
ていうか、良い説得台詞を教えてください(T_T)
実
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
checkoutされたfileをlockすることのデメリットとしては、CVS tutorial [sra.co.jp]のOHP [sra.co.jp]「衝突回避の一つのアイデア [sra.co.jp]」に挙がっています。一番つらいのは、fileを見るだけでもcheckoutするはめになること。見るだけならup-to-dateなものが必要とは限らないため、lockはするだけ無駄(どうせ変更は加えられない)です。
複数fileのlock(CVSの場合commitの禁止)はCVSROOT/availでしょうね。最も、きちんとmoduleを管理していないと使いものになりませんが、これは何を使っても同じか...
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
>checkoutするはめになること。
それは違います。
VSSなら「最新バージョンの取得」、RCSなら(たしか)ロックを伴わないco、などの
普通のCheckOutと違う機能を、使うべきものです。
管理形態の概念からして違うわけですから、「CheckOutが」使い物にならないかどうかダケを
論じるのは不味いわけでして。
蛇足ですが俺がシゴトで云々してる某OODBは、ファイルならぬ業務Objectを
ユーザーがCheckIn/Outするんですが、こいつもロック方式でして、
見たいだけのときにはCheckOutメソッドではなくShadowCopyメソッドを使います(^^;
どっちもObjectが自分の作業場ObjectにCopyされるのは同じなんですが、
リポジトリObjectに所有されている元Objectと、CopyしたObjectとの間に
「CheckOut中」関連が作成されるかどうかが違います。
この関連で繋がっていないObjectは、後からCheckInすることを許されません。
見たいためだけに取って来たものを後から心変わり(笑)してCheckInしたくなる、ってのは許してないわけです。
ロック付きでCheckOutし直してください、と。
>「衝突回避の一つのアイデア [sra.co.jp]」に挙がっています。
というわけで、同時に一人しか「アクセス」できないというのは嘘で、「更新」できないだけですね。
また、放っておかれて困ったならば、root(^^;がロックを叩き落とせばいいわけで。
#上記某OODBにもrootさんは存在します(^^;;
なので、これだけでは、ロック方式の致命的な弱点を指摘したことには、あんまりならないような気がします。