SourceSafeは本当に安全ですか?


27

午前中ずっと何かをチェックしようとして過ごしたので、今では2日間分の仕事を失いました。

その前に起こった-と明らかにSourceSafeで一般的な発生です。SourceSafeは問題なく正常に使用できますか?


40
ああ、親愛なる神NO ...二度と、二度と!
ティムポスト

27
SourceSafeを会社から追い出すために、私は長い間懸命に戦いました。最終的に勝ち、誰もがそれを喜んでいます。
ケビンD

13
VSSを使用して、任意の組織が悪い「ORG匂い」である
JoelFan

8
「早く頻繁にチェックインする」というフレーズ。このような状況を防ぐことです。数時間以上の仕事を失うことはありません。ただし、アイアンメイデンはVSSについて次のように述べています。
ライアンヘイズ

3
マイクロソフトはそれを使用しません。なぜ私たちはすべきですか?
greyfade

回答:


45

私の見解はシンプルで、できるだけ早く他の何かに移行します。長くはかからず(WAGで1〜2週間)、移行にどれだけ時間がかかっても、管理に正当なコストをかけるのは簡単です。移行する少しの時間は、確実なソース管理と、ソースコードの損失の可能性がほとんどないことを意味します。上司が懐疑的である場合は、「ソースセーフホラーストーリー」などをすばやくGoogle検索してください。


確かに、ソース管理の移行に1〜2週間かかる非技術者に正当化するのは簡単ではありません。
t3mujin

2
@ t3mujin、「技術的負債」プログラマー
Nemi

SourceSafeは、短期および長期の生産性に対する積極的かつ継続的な責任です。最新の安全な分散バージョン管理システムをいくつでも簡単に置き換えることができます。SourceSafeのホラーストーリーと専門的なガイダンスについて、Googleで調査を行います。ケースを強力に作成します。それが取るものは何でもしてください。
アダムクロスランド

3
@ t3mujin:プロジェクトごとに移行します。私が働いている場所では、以前はSourceSafeを使用していましたが、現在はTFSを使用しています。すべて(数百のプロジェクト)を移行するのは苦痛だったので、代わりに、まだSourceSafeにある古いプロジェクトで作業する必要がある場合、まず移行に少し時間を費やしてから、作業を開始します。
Carson63000

@ Carson63000現在のほとんどのプロジェクトにTFSを使用していますが、VSSの更新はほとんどありませんが、TFSへの移行を喜んで行わない大規模なソースベースがあります。私はしばらくの間に一度の用途が、それはより頻繁に私は数行のコードでOKだとチームにいないよ
t3mujin

33

最悪。SCM。今まで。

SCMの誤りはすべてVSSに組み込まれています。StarTeamでさえ、Source Safeより優れています。Source Safeは、バージョン管理の世界のInternet Explorer 1です。他の実装に完全に取って代わられています。

どのように使用しましたか?

物事を成し遂げるための私の典型的なワークフローは

  1. プロジェクトをご覧ください
  2. すべてのファイルをロックします(地獄の不浄な門を開いた誰かとのマージを避けるため)
  3. 私の仕事をしました
  4. 毎日私の変更をチェックしました
  5. もう一度チェックアウトし、統合に関するすべての問題を修正しました
  6. チェックインしました

Subversionと比較すると、上記は笑うことができます(ビルドを壊していないことを確認することは別として)。

チームのプログラミングプラクティスの制限

これらは、チームが私たちのために機能するために作業しなければならなかったルールです。あなたのマイレージは異なる場合があります。

  1. ファイルを編集できるのは1人のみです(休日に行く場合は天国が助けてくれます)
  2. 分岐しないでください
  3. 前のリビジョンに戻ろうとしない

何ができますか?

Polarionには、 Source SafeのようなものからSubversion(SVN)に移行するための優れたツールセットがあります。これは、オープンソースバージョン管理のためのほとんどの企業内の現在の事実上の標準です。Subversionには、チェックインを許可するためにサーバーを使用可能にする必要があります(オフラインの分散チーム用に設計されたGITやMercurialとは異なります)。


@Davidは、ファイルの改訂履歴を取得したり、ブランチを作成しようとしたりしません(執筆中に泣いています-私の人生の多くの無駄な時間...)
ゲイリーロウ

2
ええ、良いSCMではブランチとマージはあまり楽しくありません。議会があなたを人々にソースセーフでそれをさせることを許さないと思います。
BlackICE

2
以前のバージョンに戻ることはありませんか?何故なの?もしそうなら、SCMツールを使用する全体の目的は何ですか?
ジョエルファン

VSSを使用している店にいたとき、古いバージョンに戻るのにまったく問題はありませんでした。それは少し極端に思えます。私はあなたと一緒に分岐しています。
JohnFx

@JohnFx @SpashHit私たちのチームは痛みに対する耐性が非常に低かったので、私は少し上を向いているかもしれません。Subversionが登場したとき、それは強大な重量が持ち上げられたようなものでした。
ゲイリーロウ


11

約1年前に運用を停止しました。

前日の夕方にチェックインしたものが翌朝にはなかったことが何度か起こりました。仕事を終えていないように見えたので、面白いとは思いませんでした。私は会社が初めてだったので、それは私にとって危険だったかもしれません。

私たちはTFSに移行し、それ以来順調に稼働しています。


1
+1を取り除いて操作します。あなたは正しいことをした。
ゲイリーロウ

1
TFSは美しく、美しいものです。あなたがそれを支払うための生地を持っているなら、それはそうです。
アダムクロスランド

2
@Adam Crossland:大きなダイヤモンドのように美しく、ほぼ同じ価格。
10

1
@Orbling:よく言った。
アダムクロスランド

1
略語を認識しない人にとって、TFSはMicrosoftのTeam Foundation Serverです。
キーストンプソン

9

私の見解?

より使いやすく、より安全で、完全に無料の優れたものがあります。なぜわざわざ使用するのですか?

これは、開発の1つの領域であり、多くの選択肢があります。ほとんどまたはすべてがVSSよりも優れています。


「ほとんど」は少し戸惑っています...または別の言い方をすれば:VSSより悪いのは何ですか?
ユルゲンA.エアハルト

@jae:Mustは、すべてを使用したわけではないことを示す単なる修飾子です。したがって、VSSに関して品質を検証することはできません。したがって、「またはすべて」
スティーブンエヴァース

9

SourceSafeを商業運転で使用することは、ドル札を燃やして建物を暖房するようなものです。

2000年、私の8人の開発会社は、VSSデータベースの平均で1日2回の破損のために、おそらく生産性の5〜10%を失いました。1時間ごとのバックアップに行ったため、それだけでした。

VSSからPerforce、svn、gitに移行して以来、SCMデータベースが破損することはありませんでした。


7

私はこれについて地獄に投票するかもしれませんが、..

代替テキスト

VSSは事実上、あなたを麻薬中毒にします。これは、あなたが今壊したレポがあなたのせいではないことを理解するために必要な現実を調和させることができない程度までです。

絶対に使わないでください。


あなたが投票される可能性は低いです。私の唯一の批判は、シアン化物が明らかにVSS常習者の選択薬であることです。
Orbling

7

それを何年も使用しました-それはすでに存在していたので、デフォルトのソリューションでした。何度も噛まれたが、慣性を克服するのは難しい

その後、VPN経由でリモートで使用する必要があり、小さなチェックインでさえ、ピンホールにレンガを詰め込むようなものでした。変更されたファイルを手動で検索し、それらを圧縮し、電子メールで送信し、ソースボールトマシンにリモートで移動し、それらを解凍し、ソースボールトマシンからコードをチェックインする方が高速でした。

Mercurialに切り替えました。VPN全体のソースコードベース全体を1分以内に複製できます。そして、分岐を恐れなくなりました。

二度と戻りません。


ソースオフサイトはそのためでした。それもよく覚えています。実際にソースのコピーをオフサイトで購入したので、VPN経由でVSSを実行する必要はありませんでした
BlackICE

成熟したSCMの兆候を「分岐を恐れなくなった」ための+1
ゲイリーロウ

5

それは憎悪です。しかし、何もないよりはましです。


12
すべての選択肢があるので、使用を正当化するのは困難です。なぜなら、南に行くとき、それはあなたが持っているものだからです:何もない。
DevSolo

13
仕事を失う原因になった場合、何よりも優れているのでしょうか?
billy.bob

4
何もせずに作業を失うこともありますが、sourcesafeは少なくともあなたを時々救うことできます。
BlackICE

4
@David-潜在的に「厄介な」ことを行う前に、賢明なバックアップを行うことができます。障害でVSSに匹敵する唯一のものはMS BOBです。VSSは非常に恐ろしいので、人々がそれを使用するのを癒すという名の下に慈善団体を作成する必要があります。
ティムポスト

9
いいえ、それは何もないより悪いです。バックアップも持っていない場合、誤った安心感があり、
すべてを

5

私は個人的に問題を経験することなく長い間(10年近く)使用していました(競合などを避けるためにコードがかなりよく分割されている傾向がありましたが、作業中のチーム内を含む)。

しかし、まともで信頼性の高いオープンソースの代替が存在する場合、データ損失の話はあまりにも多くあり、それを使い続けることはできません。

編集:コメントから、メッセージは複雑なもの(分岐、マージ、競合)を避けているようで、おそらく大丈夫です。それ以上なら、あなたは危険な領域に向かっています。


チーム内で作業していましたか、それともコードベース全体のソロプロジェクトで作業していましたか?
ゲイリーロウ

チーム内では、コードベースは誰が何に取り組んでいるかという点で比較的よく分かれていたため、競合はめったにありませんでした。
ジョンホプキンス

@Jonこれは、トラブルのない操作の説明に大いに役立ちます。
ゲイリーロウ

1
FWIW私の経験はJonに似ています。7年、8人のチーム、VSSを使用しても問題ありません。どうやら私たちは(幸運な)少数派です。すべてのストーリーに基づいて(今はSVNを使用して)再び使用することはありません。
スティーブファローズ

1
マージ、分岐、および紛争解決とき...あなたはおそらく間違ったバージョン管理システムを使用している、複雑な操作と考えられている
ジェームズ

5

MSでさえTFSを支持して非推奨になっています。

Visual Studio 6またはそれより古いもので作業している単独または本当に小さな店にとって、それはまずまずで、何もないよりはましです。それがどれほど悪いかについては誇張がたくさんあると思いますが、それから価値のある仕事を失った1つのインスタンスだけで、製品を酸っぱくすることができます(正当な理由のため)。VSSがその位置を占めており、少なくともSCMツールをまったく使用していない習慣を身に着けている多くの開発者を励ましていると信じていますが、多くのテクノロジーと同様に、現在ではほとんど使われていません。


SCMの使用を開始するのは良いことであり、議論の余地はありません。しかし... VSS?悪い経験は製品に悪い名前を与えるだけでなく、カテゴリ全体に悪い名前を付けることができます。または:VSSでSCMを開始し、VSSが台無しになったときに「なんて、このSCMのものは思ったほど悪い」と思った開発者は何人ですか?SCMはインフラストラクチャの非常に重要な部分であることは言うまでもありません。つまり、バグは許可されません(ええ、私は知っています...)
ユルゲンA.エルハルト

@jaeそれは私の経験ではありませんでした。VSSはSCMへの最初の露出であり、振り返ることはありませんでした。YEARSを使用している間、データの損失、破損、問題は一切発生しませんでした。最終的には先に進みましたが、その日Visual Studioにプリインストールされていなかった場合は、ツールを統合するのに時間がかかりました。
JohnFx

3

3年使用した後、より高度で合理的な選択肢があるためにマネージャーに不平を言って、VSSで問題が発生したことは一度もありませんでしたが、選択肢もありませんでした。

私の意見では、それは吸うと吹くの両方です。

それについて最も厄介な部分は、ひどいバージョン管理とわかりにくい分岐機能ではありませんが、ファイルメニューのリストボックスでは、右矢印キーを押して展開できません。

本当に痛い。


3

VSSに関する私の見解は?彼らが「VSSの習熟度」を要求したので、私はいくつかの仕事の申し出(非常によく支払われた)を断りました。そして、私は同じことをした他の人々がここにいると確信しています。


1
+1は、仕事の広告の「VSSの習熟度」を置くことは、会社の利用VSSを行うだけでなく確かな証拠であるが、彼らはVSSがまだ破損して問題があるセットアップを持っていること、それはそれを動作させるために本物のVSSの経験を必要としていることで、すべて
Carson63000

1

ソースの破損の可能性の問題に苦しむだけでなく(これは管理者がそれを置き換えるのに十分な議論であるはずです)、また、厄介なバックアップを抱えており、さまざまな作業の流れでチームとして効率的に作業することができません。

別のSCM(他のSCM)を見つけて、分岐とマージがどれほど簡単かを調べます。VSSソリューションからファイルをコピーし、「本番」コードのバグを修正するために戻ったときにファイルを別の場所に保持しなければならなかったときのことを考えてください。

キックの場合は、GITをインストールするだけです。VSSファイルをポイントし、GASPの 2人のプログラマーが同じファイルの異なる部分を同時に操作し、ソフトウェアにインテリジェントに変更をマージするのがいかに簡単かを確認してください。ツールは単なるソースバックアップ以上のものでなければなりません。


0

VSSに関する私の見解は?長い間定期的に使用していましたが(古いコンポーネントにも使用されています)、チームにとっては20世紀です:

  • とても信頼できない
  • 使用できないブランチ
  • 非常に貧弱なバージョン管理サポート、あなたはラベルを持っていますが、(ちょうどブランチのように)実際には使用できません

上記のすべてに賛成です。waaaaayより優れたオープンソースの選択肢(古いCVSでも)の1つを選択するか、会社が何らかのMSDNサブスクリプションを持っている場合はTFSを選択します。


0
  • デフォルトのロックは開発者の速度を低下させ、誰もその設定を台無しにしたくありませんでした
  • プロジェクト管理Webアプリケーションなど、他のサービスとはうまく統合されません。
  • 計画したCIサーバーではうまく機能しませんでした

新しい2010 Team Foundationのスタッフは大いに役立ち、VSSの悪い部分から逃げようとするはずでした。しかし、そのコアはまだVSS依存しているため、SVNに移行しました。

編集 -TFSはまったく新しいものであると理解していますが、テストするときに、私が尋ねた複数の開発者はTFSに非常に似た感情を抱いていました。私が「中核」と言った理由は、VSSが作成したのと同じように見えたソリューションでTFSが作成したファイルを見たことを覚えているからです。これは開発者の観点からであり、VSSやTFS、その他のSCMの背後にある技術についても知らないかもしれません。混乱してすみません。


何!?!?TFSは、どこにでもVSSに依存しない
BlackICEは

TFSは一から書き直されました... VSSにまったく依存していません。
ルウォーディ

2
Visual Studioは、TFSとVSSに同じSCCプラグインAPIを使用します。このAPIは、あなたがVSSから変更するときに、VSSをサポートしており、それにVSSの感触を持っている任意の他のソース管理サーバー、それがVSSの幽霊がまだあるかのように感じるでしょう。
マシューマーティン

1
@LWoodyiii:それでは、どうしてこんなに熱くてがらくたの山を二度コーディングしたのでしょうか?少なくとも、VSSソースコードのコメントを読んでいる必要があります。
ロバートSチャシオ

1
@CraigTP:ほとんどのデベロッパーは、TFSのものをまったく必要としません。仕事が難しくなるのはノイズだけです。PMとリードがすべての機能を必要とする場合、開発者が生産的に使用するために必要なソフトウェアから分離する必要があります。
ロバートSチャシオ

0

当時、私はXENIXでSCCSに悩まされていました。Visual Studio 6のVSSには、障害と問題のすべてに明確な利点がありました。私は今でも小さなプロジェクトに使用していますが、SCCSはどのバージョンでも使用していません。


0

誰もがVSSを悪口にしたい理由がわかりません。VSSは分散されておらず、分散バージョン管理は

  1. より良い
  2. 実際には非分散バージョン管理が可能

これを読んでください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.