アカウント名:
パスワード:
Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...
...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重視した作りになっているようですが、そんなのは後付けでどうにでもなる(人になり代わって機械がcheckoutすれば十分)のに。 (こういう作りでいざと言う時に全く役立たずだったシステムを私は聞いたことがある)
わしも会社で試したことがあり、ファイルが消えたり はしませんでしたが、何故か更新したはずのファイルが 古い状態になったことがありました。それ以来恐ろしくて もう使えません。
#NT用のVCを手に入れるには、何故かIntel用 #エンタープライズ版が必要なのが縁でVSSが手元にあるっす。
>実際,会社で使っていますが,分岐はできます.
今仕事で使っていて, 分岐が使えるなら使いたいのですが, VSSで言うところの分岐は実際の作業では全く役に立たないことが分かりました. 最も大きな違いは, CVS等では分岐後にも幹と枝の間に関連性が維持されますが, VSSでは分岐によって完全に独立したプロジェクトとなってしまうことです.
これは次のようなシチュエーションを考えてみれば致命的に近い欠点であることが分かります
この時, VSSでは全てのbranchが独立したプロジェクトであるため個別に修正したソースの登録を人手でしなければならず, 作業ミスによるバージョン不一致が生じる可能性が高いです. さらに変更部分のマージチェックも有りませんので, branch独自の修正部分を重ね書きで潰してしまい, degradeを起こすという可能性も高くなります.
以上の欠点から, VSSを
の様な用途で使用するのは不適切であると結論付けられます
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を管理していないと使いものになりませんが、これは何を使っても同じか...
でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、大勢のひとが同時にチェックアウトできないことのデメリットはあまり際立たないですけどね。隣人に一声かけるほうが早い(^^;
これと、remote accessができないということを考えると、開発者を全員1つの部屋に閉じ込められるならSourceSafeでも何とか使えるんでしょうかね。商用のツールでもperforce [perforce.com]のようにremote accessができるものがある(bkもそうらしい)ので、使い方に気が付いていないだけの問題でしょう。
人数はあまり関係ないのでは? 私が関わってることなんか、USに数名、ヨーロッパに数名、日本に1名(あっし)って状態ですから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
コードフィックスと言う概念 (スコア:1)
確かにVSS使ってますが、いつまでたっても機能追加できてしまうエンドレス管理システムだったりする。
結局、MSの製品のバージョンって「見栄えの違い」以外認識できない気がする今日この頃です。
Windowsだって、結局いろんな機能拡張が出てきてWindows95でも、
WindowsXPでも似たような事ができてしまっ
職業としてのプログラマ
Visual SourceSafe 6.0を見てみたけど (スコア:2, 興味深い)
Visual SourceSafeの機能 [microsoft.com]を簡単に調べてみましたが...
...これじゃ、rcsよりひどくないですか? (rcsにもbranchはある) 並行開発が全く不可能です。どちらかというとdaily buildを重視した作りになっているようですが、そんなのは後付けでどうにでもなる(人になり代わって機械がcheckoutすれば十分)のに。 (こういう作りでいざと言う時に全く役立たずだったシステムを私は聞いたことがある)
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
これは嘘でしょう.(ココ [microsoft.com])
実際,会社で使っていますが,分岐はできます.
ただ,その機能を使ったことはありません.
# 他のプロジェクトでは,分岐を使用しています.
そもそも,VSSは非常に使いにくいので,使い続けたくはありません.
ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.
VSSを使えば使うほど,MS社以外の生産性を落とさせるための陰謀じゃないかと,疑いたくなります.
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
>ファイルが消えたりとか,バックアップするには,どのファイルを取っておけば良いのか(レジストリも必要なのか?)とか,不安な要素も他にあります.
わしも会社で試したことがあり、ファイルが消えたり
はしませんでしたが、何故か更新したはずのファイルが
古い状態になったことがありました。それ以来恐ろしくて
もう使えません。
#NT用のVCを手に入れるには、何故かIntel用
#エンタープライズ版が必要なのが縁でVSSが手元にあるっす。
BURRN!
やっぱり分岐はダメ (スコア:1)
>実際,会社で使っていますが,分岐はできます.
今仕事で使っていて, 分岐が使えるなら使いたいのですが, VSSで言うところの分岐は実際の作業では全く役に立たないことが分かりました. 最も大きな違いは, CVS等では分岐後にも幹と枝の間に関連性が維持されますが, VSSでは分岐によって完全に独立したプロジェクトとなってしまうことです.
これは次のようなシチュエーションを考えてみれば致命的に近い欠点であることが分かります
この時, VSSでは全てのbranchが独立したプロジェクトであるため個別に修正したソースの登録を人手でしなければならず, 作業ミスによるバージョン不一致が生じる可能性が高いです. さらに変更部分のマージチェックも有りませんので, branch独自の修正部分を重ね書きで潰してしまい, degradeを起こすという可能性も高くなります.
以上の欠点から, VSSを
の様な用途で使用するのは不適切であると結論付けられます
Re:Visual SourceSafe 6.0を見てみたけど (スコア:1)
というか、たしか、デフォ設定がロック型管理になっているというだけだったような記憶が。
ただ、共同所有について開眼(笑)していない人、つまり
そのメリットを知らず、デメリット(というか憶測にもとづく恐怖?)ばかりを信じて
いる人々にとっては、ロックがかからない管理方法ってのは
本能的(笑)に怖くなるようですね。
コードを書いたひとが後々のデバッグのセキニン(笑)まで負う、
などという呑気なモデルを未だに採用してるトコロには、
VSSは似合いのツールなんじゃないかな :-P
ていうか、良い説得台詞を教えてください(T_T)
実際にはファイルをロックしても「他のファイルとの関連」をロックできるわけじゃないんで
ロックなんて徒労なんだけども、それを理解してもらうのは至難ですぅ…
でもまあ、大人数(大企業にせよオープンソースにせよ)でナイ場合には、
大勢のひとが同時にチェックアウトできないことのデメリットは
あまり際立たないですけどね。隣人に一声かけるほうが早い(^^;
ところでVSSは、MSのソフトとは思えないほど(笑)比較的使いごこちは良いと思います。
あくまで比較的です。wordやexcelのような、何年たっても慣れられない
変な操作性は、あんまり無いです。
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さんは存在します(^^;;
なので、これだけでは、ロック方式の致命的な弱点を指摘したことには、あんまりならないような気がします。
人数および配置とツール (スコア:1)
これと、remote accessができないということを考えると、開発者を全員1つの部屋に閉じ込められるならSourceSafeでも何とか使えるんでしょうかね。商用のツールでもperforce [perforce.com]のようにremote accessができるものがある(bkもそうらしい)ので、使い方に気が付いていないだけの問題でしょう。
人数はあまり関係ないのでは? 私が関わってることなんか、USに数名、ヨーロッパに数名、日本に1名(あっし)って状態ですから。
Re:人数および配置とツール (スコア:1)
なるほど。たしかに問題はショバのほうですね。
一個所に集まってるならば声かければ済む。部屋とかを跨いでいると面倒。
#昨今の日本人が大好きな、「顔の見える血の通ったコミュニケーション」ですね(笑)
まぁchatだかなんだかで「声」をかけて操作してもらうことは有りますが。「あれCheckInしてちょーだい!」とかね。
ロック方式は、よくもわるくも(笑)、修正「責任」という考え方ですね。
お前の仕事なんだからお前がセキニンもって更新しCheckInしろ、という奴。
ただ、実際のシゴト(嫌な言葉だ)においては、XPしてるんでもない限り、ソースだのドキュメントだの
ワードやエクセルのファイルだの(笑)を編集するにあたっては、たいていの場合、この責任ベースの考え方で
シゴトが運用されてるような気がします。誰でも更新できる人が更新できるときにしてちょ、と言われる
ってことは、あんまり多くないんじゃないかなーと。
で、責任をバージョン管理ツールレベルで(でも)明示的に把握できるという意味で、
ロック方式はそういう仕事形態と、相性が良いのかなと。
多分これも「現場は思い込みによって非効率なことをしている」例のひとつなんだとは思いますが、まぁどうしたものか…
>remote accessができるものがある(bkもそうらしい)ので
VSSがremoteできるかどうかを未だに把握してない俺(ぉぃぉぃ
ところでCVSって、ファイルの「リネーム」にテコズるんでしたっけ?
#それゆえにリファクタリングを阻害する、という意見を聞きました。
VSSだと楽勝なんですが…(^^;