パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Redmondのバグ潰し月間」記事へのコメント

  • わざわざ言う辺り、MSには「コードフィックス」と言う概念がないんでしょうね。
    確かにVSS使ってますが、いつまでたっても機能追加できてしまうエンドレス管理システムだったりする。

    結局、MSの製品のバージョンって「見栄えの違い」以外認識できない気がする今日この頃です。

    Windowsだって、結局いろんな機能拡張が出てきてWindows95でも、
    WindowsXPでも似たような事ができてしまっ
    --
    職業としてのプログラマ
    • by brake-handle (5065) on 2002年02月04日 20時09分 (#59811)

      Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...

      • fileをcheckoutしたらcheckinまで他の人は一切いじれない(設定変更が必要)
      • 1つのprojectがsplitすることを考慮していない(branchが切れない、mergeができない)

      ...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重視した作りになっているようですが、そんなのは後付けでどうにでもなる(人になり代わって機械がcheckoutすれば十分)のに。 (こういう作りでいざと言う時に全く役立たずだったシステムを私は聞いたことがある)

      親コメント
      • > * 1つのprojectがsplitすることを考慮していない(branchが切れない、mergeができない)

        これは嘘でしょう.(ココ [microsoft.com])

        実際,会社で使っていますが,分岐はできます.
        ただ,その機能を使ったことはありません.
        # 他のプロジェクトでは,分岐を使用しています.

        そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
        ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.

        VSSを使えば使うほど,MS社以外の生産性を落とさせるための陰謀じゃないかと,疑いたくなります.
        親コメント
        • >そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
          >ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.

          わしも会社で試したことがあり、ファイルが消えたり
          はしませんでしたが、何故か更新したはずのファイルが
          古い状態になったことがありました。それ以来恐ろしくて
          もう使えません。

          #NT用のVCを手に入れるには、何故かIntel用
          #エンタープライズ版が必要なのが縁でVSSが手元にあるっす。

          --
          BURRN!
          親コメント
        • by SteppingWind (2654) on 2002年02月05日 11時44分 (#59987)

          >実際,会社で使っていますが,分岐はできます.

          今仕事で使っていて, 分岐が使えるなら使いたいのですが, VSSで言うところの分岐は実際の作業では全く役に立たないことが分かりました. 最も大きな違いは, CVS等では分岐後にも幹と枝の間に関連性が維持されますが, VSSでは分岐によって完全に独立したプロジェクトとなってしまうことです.

          これは次のようなシチュエーションを考えてみれば致命的に近い欠点であることが分かります

          • ユーザに製品をリリースしているが, このユーザ向けのカスタマイズが含まれているため分岐して管理している.
          • バグが見つかったので修正しなければならないが, これは共通部分だったので全てのbranchに適応しなければならない

          この時, VSSでは全てのbranchが独立したプロジェクトであるため個別に修正したソースの登録を人手でしなければならず, 作業ミスによるバージョン不一致が生じる可能性が高いです. さらに変更部分のマージチェックも有りませんので, branch独自の修正部分を重ね書きで潰してしまい, degradeを起こすという可能性も高くなります.

          以上の欠点から, VSSを

          • 本番系保守と開発が平行して進むような長期・大規模プロジェクト
          • 複数のリリースバージョンを平行して保守するようなプロダクトカスタマイズシステム開発

          の様な用途で使用するのは不適切であると結論付けられます

          親コメント
      • >他の人は一切いじれない(設定変更が必要)

        というか、たしか、デフォ設定がロック型管理になっているというだけだったような記憶が。

        ただ、共同所有について開眼(笑)していない人、つまり
        そのメリットを知らず、デメリット(というか憶測にもとづく恐怖?)ばかりを信じて
        いる人々にとっては、ロックがかからない管理方法ってのは
        本能的(笑)に怖くなるようですね。

        コードを書いたひとが後々のデバッグのセキニン(笑)まで負う、
        などという呑気なモデルを未だに採用してるトコロには、
        VSSは似合いのツールなんじゃないかな :-P

        ていうか、良い説得台詞を教えてください(T_T)
        実際にはファイルをロックしても「他のファイルとの関連」をロックできるわけじゃないんで
        ロックなんて徒労なんだけども、それを理解してもらうのは至難ですぅ…

        でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、
        大勢のひとが同時にチェックアウトできないことのデメリットは
        あまり際立たないですけどね。隣人に一声かけるほうが早い(^^;

        ところでVSSは、MSのソフトとは思えないほど(笑)比較的使いごこちは良いと思います。
        あくまで比較的です。wordやexcelのような、何年たっても慣れられない
        変な操作性は、あんまり無いです。
        親コメント
        • 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を管理していないと使いものになりませんが、これは何を使っても同じか...

          親コメント
          • >一番つらいのは、fileを見るだけでも
            >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さんは存在します(^^;;

            なので、これだけでは、ロック方式の致命的な弱点を指摘したことには、あんまりならないような気がします。
            親コメント
        • でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、大勢のひとが同時にチェックアウトできないことのデメリットはあまり際立たないですけどね。隣人に一声かけるほうが早い(^^;

          これと、remote accessができないということを考えると、開発者を全員1つの部屋に閉じ込められるならSourceSafeでも何とか使えるんでしょうかね。商用のツールでもperforce [perforce.com]のようにremote accessができるものがある(bkもそうらしい)ので、使い方に気が付いていないだけの問題でしょう。

          人数はあまり関係ないのでは? 私が関わってることなんか、USに数名、ヨーロッパに数名、日本に1名(あっし)って状態ですから。

          親コメント
          • by G7 (3009) on 2002年02月05日 22時49分 (#60184)
            >人数はあまり関係ないのでは?

            なるほど。たしかに問題はショバのほうですね。
            一個所に集まってるならば声かければ済む。部屋とかを跨いでいると面倒。
            #昨今の日本人が大好きな、「顔の見える血の通ったコミュニケーション」ですね(笑)

            まぁchatだかなんだかで「声」をかけて操作してもらうことは有りますが。「あれCheckInしてちょーだい!」とかね。

            ロック方式は、よくもわるくも(笑)、修正「責任」という考え方ですね。
            お前の仕事なんだからお前がセキニンもって更新しCheckInしろ、という奴。

            ただ、実際のシゴト(嫌な言葉だ)においては、XPしてるんでもない限り、ソースだのドキュメントだの
            ワードやエクセルのファイルだの(笑)を編集するにあたっては、たいていの場合、この責任ベースの考え方で
            シゴトが運用されてるような気がします。誰でも更新できる人が更新できるときにしてちょ、と言われる
            ってことは、あんまり多くないんじゃないかなーと。

            で、責任をバージョン管理ツールレベルで(でも)明示的に把握できるという意味で、
            ロック方式はそういう仕事形態と、相性が良いのかなと。

            多分これも「現場は思い込みによって非効率なことをしている」例のひとつなんだとは思いますが、まぁどうしたものか…

            >remote accessができるものがある(bkもそうらしい)ので

            VSSがremoteできるかどうかを未だに把握してない俺(ぉぃぉぃ

            ところでCVSって、ファイルの「リネーム」にテコズるんでしたっけ?
            #それゆえにリファクタリングを阻害する、という意見を聞きました。
            VSSだと楽勝なんですが…(^^;
            親コメント

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

処理中...