私はここのほとんどの人がSVNは金メッキの良さだと思う傾向がありますが、VSSはこれまでに考案された中で最悪のプログラムです（少なくともバージョン管理に関しては）。
そうは言っても、なぜですか？私はいくつかのCVSを使用しましたが、現在の仕事はVSSを使用しています。チームの観点からすると、それほど大きな違いはわかりません。私が見た違いのほとんどは表面的なものです。確かに、私は分岐/マージも試みていませんが、入ってくるコーダーとして、ファイルをチェックアウトし、それらのファイルを処理して、一日の終わりにチェックインします。なぜ私は1を超えたいのですか？他の？
Visual Source Safe を作成している Microsoft は、かなりの規模のプロジェクトに対して社内で使用していません。私の本では、それはそれに対する主要なマークです。大規模なプロジェクトに使用すると、その理由がわかります。それは遅いので、何かを自動マージさせることにした場合は、神が助けてくれます。
VSS はアトミックではないため、別のユーザーからの大規模なチェックイン中に最新のものを取得すると、ファイル セットが不完全になります。VSS は共有を介して動作するように設計されているため、WAN を介して動作する場合も、これはさらに悪化します。
私の最後の 2 つ目の会社は、次の理由で VSS から SVN に切り替えました。
VSS は簡単に選択できることはわかっていますが、いくつかのことを覚えておくことが重要です (雑草から抜け出してください!)。
これらすべての点で私に同意する必要はありません。私は、それが適切な場所にあり、さまざまなシナリオで価値があることを示しているだけです。
Java コードを使用した VSS に問題があります。getLatestVersion の場合、VSS は Java のプロジェクトとパッケージのネストされた構造を処理できません。同じフォルダー構造を無限に持っています。この点で、SVN は非常に単純です。
VSS には、克服しなければならない本当に悪い歴史があります。最近のバージョンはより安定しているように見えますが、それでも持ち歩いている負の荷物が大量にあります。
できるだけ早く VSS から実行する必要があります。過去に問題がなかった場合は、何らかの問題が発生している可能性があります。ロシアンルーレットの時限爆弾のようなもので、いつ爆発するかわかりません。
SVN は優れたツールであり、セットアップと管理が非常に簡単です。バックアップまたは複製用の管理ツールは非常に優れています。
いつでも VSS よりも SVN をお勧めします。
Visual Studio での統合の古い議論は、もはや機能しません。AnkhSVN 2.0は統合ソリューションを提供し、VisualSVNは TortoiseSVN を Visual Studio に統合します。
また、TortoiseSVN自体は、多くのユーザーにとって切り替える十分な理由です。
機能に関しては、CVS と VSS はほとんど同じものです。したがって、それぞれを比較するための出発点としては適切ではありません。
ただし、SVN と VSS をチームのうなり声として使用するだけであれば、おそらく違いは見られないでしょう。分岐、マージなどの違いを実際に確認するには、プロジェクトマネージャーとしてそれらを実際に使用し始める必要があります.
SVN は開発者の観点からはうまく機能しますが、ディレクトリ ツリー全体に構成情報を保存する方法は、システム管理者 (特に、開発者がコミット/再チェックアウト プロセスの実行を拒否したときに別のサーバーに移動するタスクを課されたシステム管理者) を怒らせます。:) だから、それはすべて金メッキの良さではありません!
実際、Perforce は金メッキの良さだと思います。GUI ツールは十分に優れているため、デザイナーやアーティストに渡して、私たち開発者のようにソース管理を使用してもらうことができます。VSS File->Add Files ウィンドウは Windows 95 よりも前のものであると確信しています。使用中のファイルがロックされているという全体的な概念はばかげています。何十年も前に CONCURRENT バージョニングで解決しなかったのでしょうか? 私は履歴の破損を経験しましたが (間違っていたら訂正してください)、VSS はブランチとマージさえサポートしていません。