私の開発チームは、非常に基本的なレベルでソース セーフを使用しています。私たちは、より高度で拡張された開発サイクルに移行しており、変更を管理するために分岐とマージを使用しないことは、すぐに私たちを苦しめるだろうと思わずにはいられません。
SVN のようなより優れたソリューションに移行するようチームを説得するために、どのような議論が最も役に立ちましたか?
チームが ide ソースセーフの統合を見逃さないように、機能のギャップを埋めるためにどのプログラムを使用しましたか?
それとも、ソースセーフを受け入れて、より良いプラクティスを押し付けようとするべきですか?
SVN はオープンであり、SVN を使用または連携するさまざまなツールが豊富にあります。いくつかの例は次のとおりです。
まず、効率的な方法で SourceSafe を使用する方法を教えます。
彼らが十分に賢ければ、バージョン管理システムを使用する利点を気に入るようになるでしょう。そうであれば、すぐに SourceSafe の限界に達するでしょう。チームが何を達成する準備ができているかに応じて、CVCS または DVCS である可能性がある、より優れた VCS に切り替えるための議論に耳を傾けることができる場所です。
ソース コードの zip ファイルを保存するなど、間違った方法で SourceSafe を使用しているときに別の VCS を使用するように強制しようとすると (笑わないでください。2 年前に私の会社で彼らが行っていた方法です)、彼らは完全に消極的になります。あらゆる議論に、可能な限り。
C# コードで非 ASCII 文字の使用を開始する口実を見つけてください(これには中国語と日本語が適しています)。
SourceSafe は (Visual Studio は好きですが) Unicode を好みません。そのため、適切な Unicode テキストを選択してファイルをチェックインおよびチェックアウトすると、ファイル全体が破損した意味不明なものとして表示されます。これの優れた点は、SS は「差分」バージョン管理システムを使用しているため、実際には元のチェックイン バージョンまでファイルが破損し、自動的に修正できないことです。
これが 1 回だけ発生した場合 (日本語をサポートしなければならないアプリケーションで作業していたときのように)、おそらく SourceSafe を削除する決定的な理由になるでしょう。
VSS を介して SVN で管理とチームを販売するために使用した 2 つの機能がありました。
1) 分岐する能力。VSS を使用している場合、リリースが予定されている場合、リリースが実際にリリースされるまでリポジトリ全体がロックされていました。これには、テストと修正のサイクルが含まれます。そのため、開発者は、リリースの修正以外は VSS リポジトリにコミットできませんでした。これにより、各リリース直後の長い統合セッションが発生しました。SVN でリリース ブランチを使用すると、リポジトリ全体をロックする必要がなくなります。
2) 変更全体を一度にロールバックする機能。SVN は変更されたすべてのファイルを単一のアトミック コミットで記録するため、問題のある変更を元に戻すのは簡単です。VSS では、開発者はリポジトリ全体を調べて、ほぼ同時に変更されたすべてのファイルを見つけ、各変更を各ファイルに個別に戻す必要がありました。SVN を使用すると、関連するコミットを見つけて、TortoiseSVN の [このコミットから変更を元に戻す] ボタンをクリックするだけで済みます。
補足として、私たちは TortoiseSVN を使用しており、変更されたものと変更されていないものを確認するためのファイル オーバーレイ アイコンを誰もが気に入っています。
何をするにしても、ゆっくり動かしてください！1 日目から分岐について話し始めないでください。先延ばしにするだけです。私はそのコメントで VSS ユーザーをステレオタイプ化していますが、それは私が見ているものです。
開発者向け: VSS の代わりとして、より良く、より速く動作するものとして販売してください。初日は VisualSVN を使用して、学習曲線を非常に浅くします。より速く、より安定しており、2 人が同じファイルを編集できることを除けば、同じであることを売り物にします。
管理者向け: VSS よりも安定しており、管理が容易であることを売り込んでください。それらにVisualSVN serverを表示します。
幸運を！
まず、ソース管理システム内の根本原因を突き止めることができる、発生しているすべての問題を文書化します。それらを1か月ほど追跡します。それを使用しないために失われた機会に加えて。(「Subversion を使用しないことの機会費用」と言うと、MBA タイプのマネージャーに感銘を受ける可能性があります)。これらの数値は実際には機会費用を過小評価しています。なぜなら、VSS をいじっていなければ、1 時間あたりの請求額以上の価値を提供する仕事をしていた可能性があるからです。
たとえば、複数のユーザーがアクセスする必要があるファイルがロックされているという問題がありますか? 部分的な (非アトミックな) チェックインで問題が発生したことがありますか? ソフトウェアのリリースを追跡し、過去のようにリポジトリを再作成することが難しいという問題がありますか? ソースセーフなクライアントを持たないサーバーにコードのコピーを取得する際に問題がありますか? 継続的インテグレーション ツールがバージョン管理システムの更新を監視できないため、ビルドおよびテスト プロセスの自動化に問題がありますか? 他にもたくさん考えられると思います。
sourcesafe によって引き起こされる問題のおおよその時間/お金のコストと、Subversion が提供するものの利点 (人件費または単に時間に 100 ドル/時間などの一般的な数値を使用) と、プロジェクトの遅延配信のコストを把握できる場合は、そうしてください。 . 1 か月程度のデータを収集した場合は、1 か月あたりの Subversion を使用してメリットを示すことができます。
次に、Subversion への移行にかかるおおよその時間とコストを提示します。(セットアップとコードの移行に約 8 時間、開発者 1 人あたりプロジェクトの接続、チェックアウト、移動に 2 時間など) ロールバックするソースセーフがまだ存在するため、リスクは低くなります。
費用が毎月の利益よりも多い場合は、費用を利益で割って回復期間を計算できます。また、長期的な利益を示すために、3 年程度にわたって合計する必要があります。繰り返しになりますが、ソース セーフで非分岐リリースを管理しようとしている間に価値を追加できた可能性があるため、実際の機会費用は直接計算できないことを強調してください。
Microsoft でさえも、SourceSafe の使用を推奨する人は誰もいません。代わりに (高価な) TFS ライセンスが提供されるようになりました。SourceSafe は信頼できません。
私はそれについてここに書きました: Visual SourceSafe on E2。少し大袈裟ですが、それは私が SourceSafe をかなり長い間使用しなければならなかったからです。
信頼性はあなたを噛む大きなものです。しかし、SVN や TFS には次のような便利な機能もあります。
TFS と SVN はどちらも複数のファイルのアトミック コミットを持っていますが、Sourcesafe はそうではありません。2 つのファイルを「一度に」チェックインする場合、それは 1 つの操作ではなく、ファイルの 1 つをチェックインしてからもう 1 つをチェックインするのと同じです。1 つのファイルがチェックインされ、もう 1 つのファイルがチェックインされていない、その間の状態を取得できます。
SourceSafe は、削除されたファイル、ファイルの移動、または名前の変更の履歴を保持しません。
最初の印象に反して、適切なオプションを設定すると、SourceSafe は同じファイルの複数の同時チェックアウトをサポートします。しかし、TFS、特に SVN は、この作業方法に適した設計になっています
SourceSafe とは異なり、TFS と SVN はどちらもインターネット上のサーバーに対して正常に動作し (TFS は問題ありませんが、SVN は非常に優れています)、SVN はオフラインでも問題なく動作します。たとえば、飛行機や電車にラップトップがあり、ネットがない場合でも、作業して比較することができます。これを行うデータはローカルに保持されているため、以前のリビジョンに戻すことも、元に戻すこともできます。
他の誰かが指摘したように、CVS と同様に、SourceSafe は「死んだ」製品です。積極的に開発されていません。TFS と SVN は、将来的に次のバージョンをリリースする予定です。
VSSリポジトリをSVNリポジトリにミラーリングする自動化を構築する
コンセンサスを構築するには時間がかかります。VSSリポジトリのSVNミラーが常に利用可能であれば、変換を蓄積するのが簡単になります。ミラーは完璧である必要はありません-それはただ使用可能である必要があります。この目的のための既存のツールがあります。
TortoiseSvn (無料) は、エクスプローラーとの統合に非常に優れており、コンテキスト メニューから svn のすべての機能を利用できます。
VisualSvn (商用) を使用すると、svn を Visual Studio に簡単に統合できます。ソリューション ブラウザーとコンテキスト メニューに同じステータスが表示され、すべての Subversion 機能を使用できます。
これらのツールはどちらも、バージョン管理をシームレスにするのに大いに役立ちます。私が VSS を扱ってから数年が経ちましたが、これらのツールはソース管理を使用するための優れた方法です。
VSSがうんちであることについて誰もが言ったことと同じ
Subversion は、分岐とマージを適切にサポートしています... VSS がこの部門で何らかの機能を持っていたのをまったく覚えていません。チームが VSS からリリースする必要があるときに 1 週間のマージの苦痛を経験したことを覚えています。この苦痛は Subversion ではもう存在しません。
あなたは、「SVN のようなより良いソリューションに移行するようチームを説得するために、どのような議論が最も有用だと思いましたか?」と言います。
それがより良い解決策であることがわからない場合、なぜあなたは議論をしているのですか? 解決策を議論するのに十分な決心がついている場合は、それらの理由がすでに何であるかを知っておく必要があります.
より良いものに移行する必要があると確信したのは何ですか? それらはあなたの議論です。これらの議論に欠けているものは、単なる個人的な好みの問題のように聞こえます.
VS 用の AnkhSVN プラグインは非常に優れています。いくつかの奇妙な点がありますが、全体的にうまく機能します。
チームに移動するよう説得するのは大変な作業です - 私はそれを管理できませんでした :-( おそらくより実用的な議論の 1 つは速度です - 1 GB のソース データベースと複数のユーザーがある場合、VSS は遅くなります。
編集VSS を使用してから長い時間が経ちましたが、ロックされていることを忘れていました。はい、ここで述べたように、少数の開発者がいる場合は、非排他的/マージ変更モデルに移行する機能が役立つはずです。オフィス全体で「誰かが共通のインクルードをチェックインできますか」と叫ぶ必要がなくなります。
私たちにとってのクリンチャーは、VPNを介したVSSと道路上の低帯域幅のホテルネットワークの速度（つまり、その欠如）と、2つの異なるサイトの2つのチームが迅速、安全、かつ確実にファイアウォールをトンネリングしようとする問題でした。同じコードリポジトリから作業します。2つのVSSリポジトリを実行し、同期を維持するために他のサイトのリポジトリにマージする必要のある「配信」をパッケージ化していました。
チームはしばらく不平を言ったが、すぐにそれを乗り越えた。TortoiseSVNはそれ自体が素晴らしく、Visual Studio用のAnkhSVNプラグインは、誰もが切り替えを簡単に行えるようにしました。
振り返ってみると、「SoAndSoファイルをチェックインできますか？」がいくつあるか信じられません。「SourceSafeがダウンしています。リポジトリを復元する必要があります」という電子メールは言うまでもなく、私たちが送信した電子メール。
シーシュ。このコメントを読んでこの回答を書いた後、私たちがそうしている限り、VSSに我慢できたとは信じられません。
VSS に関する問題をまとめた Web ページ- その URL に人々を誘導するだけです
VisualSVN を使用すると、チームは VSS を見逃すことはありません。2 人が同時に 1 つのファイルで作業できることも大きなセールス ポイントです。
ソースセーフの信頼性の低さ (「リポジトリを修正してください...」) は、私たちにとって十分な売り込みでした。余談ですが（測定したことはありません）、SVNも常に高速に見えます。優れた同時チェックアウト/マージ。
私はいつも、開発者にとってそれはあまりにも明白すぎると思っていました。SourceSafe は、置き換えたくないほど頻繁に壊れたり死んだりするようです...
この製品を気に入った SourceSafe ユーザーはいないと思います。あなたの同僚は実際にそれが好きですか？
私の現在の顧客の使用法で、CVS に同様の問題があります。「それはうまくいく」ので、彼らはそれにほとんど満足しているので、私は彼らに変更を強要することはできません. しかし、毎日私は彼らがそうしてくれることを願っています！
将来的には Subversion に変更することを視野に入れて、ソースセーフな使用法にベスト プラクティスを導入し始めることをお勧めします。これにより、実際のサブバージョンの移行が容易になり、開発サイクルや分岐戦略などを計画する時間が得られることを願っています。ちゃんと。
考慮すべきもう 1 つのことは、一般的な開発プロセスです。ソース管理システムはソリューションの一部にすぎません。subversion やその他の製品を最大限に活用するには、その使用法がコード レビュー、qa、およびビルド プロセスとどのように相互作用するかを確認する必要があります。
私が VS2005 のローンチを行っていたとき、私はなんとか Microsofty を追い詰め、なぜ SourceSafe がそれほど使いにくいのかを尋ねました。彼が言ったことだけでなく、彼が言ったことについてとても率直だったので、私が得た返事はかなり衝撃的でした.
彼は、それは本当に一人の人だけが使うことを意図しており、それでもそれを行うのはあまり得意ではないと私に言いました.
同僚と私は、Microsofty のように大声で笑う以外に何も考えられないことに少しショックを受けました。その後、彼はそれが内部で使用されていないことを教えてくれました。
そのため、その後すぐに Subversion に切り替えました。ローンチイベントの前にそれをやろうとほぼ決めていましたが、それは正しい決定をしたことを確認しただけです.
彼らにそれを使わせてください、そうすれば彼らは何か他のものに切り替わります:)
さて、真剣に、それを使用するのはそれほど難しくないことを彼らに伝えてください、私が知っている多くの開発者は、subversionをunixおよびwierdコマンドに関連付け、ToirtoiseSVNやVisualSVNのようなインターフェースを示し、Subversionがそれらを可能にすることを彼らに伝えますVSSのように強制的にロックせずに同じファイルを編集します。
そして最後になりましたが、それはオープンソースです。Team Foundation Serverを購入するよりもコストが低く、周りを見渡すと、開発者の小さなチームがSVNで非常にうまく機能していることがわかります。
また、TracはSubversionの上にマウントされます。これは無料で、リポジトリ（タイムライン、ウィキなど）を表示するための優れた方法です。
別のバージョン管理システムで SourceSafe を使用しない場合は、SVN ではなくMercurialを使用することをお勧めします
Joel Spolsky はMercurial の非常に優れた紹介を書いており、Visual Studio のプラグインも使用できます。
このトピックに関する優れた本は、「Driving Technical Change」です。
ソース セーフを使用するだけで、別のソース管理システムに移行する十分な理由になるでしょうか?
以前の仕事では SVN と CVS を使用していましたが、ソース セーフを使用する会社に移りました (SVN に移行する予定です)。前職の同僚の多くが VSS に関する恐ろしい話を私に話してくれたにもかかわらず、私は心を開いて入社しました。
他の誰かがファイルを編集している/編集していたためにファイルを編集できないのはばかげています。cannonical によって作成された Bazzar のような、より分散されたバージョン管理システムに移行しようとしましたが、利用可能なツールに関しては十分に成熟していません。
ソース セーフは、SVN がほぼすべての段階で役立つ開発の邪魔になります。
さらに、tortoise Svn を使用すると、コード レビューがはるかに簡単になりました。
以前の仕事では、VSS から始めて SVN に移行し、後戻りすることはありませんでした。
新しい仕事を始めたばかりで、VSS を使用していますが、幸いなことに、上記の問題により、SVN の使用を検討しています。
誰かがプロジェクト ファイルをチェックアウトしたためにプロジェクトにファイルを追加できないのは腹立たしいことです。
-- リー
私が 3 人のチームで働いていて、彼らが数を増やし始めたときはいつでも、VSS から遠ざかることは自然なステップのように思えました。
また、継続的インテグレーション(具体的にはCruiseControl.NET )の利点を人々に示したときはいつでも; 多くの場合、それ自体が VSS から SVN への移行を正当化するのに十分です (SVN は VSS よりも CruiseControl.NET ではるかにうまく機能することがわかりました)。
SVN で新しいプロジェクトを開始し、必要に応じて古いプロジェクトを移行することをお勧めします。1 つのステップで完全に移動するのではありません。
この方法で VSS がどれほど速く消滅するかに驚かれることでしょう。
あなたはたくさんの猫を群れにすることができるので、その範囲だけです。私は 2 回行ったことがありますが、どちらの場合も、人々が光を見る前に、Source Safe で深刻な問題が発生しました。一方、マネージャーとして、私は単にチームに SVN を使用するように指示しただけで、生産性が 300% 向上しました (これはインドと米国のグループと協力していました。以前は svn の前に長い時間がかかっていたコード交換がありました)。
これらの議論を行う際には、オープン ソース ツールの使用に関して会社が持つ可能性のあるポリシーに対処する必要があるかどうかを検討してください。前の質問に対するこの回答を参照してください: ソース管理の切り替え
私は、10 年以上もの間 SourceSafe を使い続けてきたので、数週間以内に SourceSafe を捨てるつもりです。ほとんどの場合、私は小さな (< 5 人) チームのコンテキスト内でそれを使用してきましたが、それを行うように求められていないため、多くの分岐を行う必要はありませんでした。
ただし、私にとっての最大の問題は、これまで常にそうであったことですが、ネットワーク ドライブに SS データベース (笑、データベース。ランダムに名前が付けられたファイルのコレクションをより正確に説明します) がある場合、いまいましいことが非常に破損しやすいということです。 、追加/チェックイン操作の途中で LAN 接続に何かが発生します。
数か月前、私は過去 10 年間、自分が取り組んでいるソフトウェアのリリースごとにソースのローカル zip コピーを作成していたことに気付きました。ソース管理システムを信頼していなかったからです。時間の無駄です。
それで、それは行きます。チームには移行を容易にするための UI が必要になると思うので、おそらく Subversion と TortoiseSVN を使用します。
以前は SourceSafe を使用していました。その後、私がチームに参加したとき、私は別の場所にいました。最新バージョンをチェックアウトしようとすると、LAN はかなり良好でしたが、40 分かかりました。私は彼らに CVS に変換するよう説得し (現在は SVN を使用しています)、チェックアウトにかかる時間は数分に短縮されました。SourceSafe は、遠隔地で使用するには遅すぎました。
SourceSafe から Source Gear Vault に移行しました。このソース管理エンジンは、SourceSafe に慣れている人にとっては非常に快適です。重要な時期に発生したいくつかの SourceSafe の破損事件の後、最終的に変更を行うことにしました。したがって、セールス プレゼンテーションでは SourceSafes の信頼性の低さに焦点を当てることをお勧めします。
私は小規模な開発チームで SourceSafe を使用し、その実行を維持する責任を負っていました。
私は、データベースが非常に簡単に破損することを発見しました。「修復」機能 (ほとんどの Microsoft 修復機能と同様) は、98% の確率で機能しません。
当然のことながら、データベースが破損したときは、バックアップ アーカイブから復元しようとしました。そのとき、SourceSafe のもう 1 つの悪い点を発見しました。2 GB のアーカイブ制限です。私たちはオフィスで何ヶ月もバックアップを作成していましたが、復元できず、役に立たないことに気づきました。
SourceSafe は、起こるのを待っている災害です。