このあたりでは、約10年ほどの間、多数のVisualSourceSafeリポジトリを使用してきました。
次に、sourcesafeを削除して、TeamFoundationServerに移動します。
この移行に着手する前に、ヒントやコツはありますか？私が注意しなければならないことは何ですか？
この移行は、私たちの作業習慣を何らかの方法で変更する必要があることを意味すると確信しています。これらの変更は組織にとって問題になる可能性があると思いますか？1つのサイトに約20人の.NET開発者がいるグループについて考えてみてください。
移行する方法はいくつかあります。ツールは履歴などをプルしますが、より実用的で簡単な方法は、VSS を履歴アーカイブとしてロックし、最初からやり直すことです。
変換前の履歴については、VSS にアクセスする必要がありますが、1 週間か 2 週間後には、それほど頻繁に発生する可能性は現実的に低いです。また、VSS の履歴は正確であり、変換プロセスによって破損していないことがわかっています。
VSS のように、TFS は異なるプロジェクト間でのファイルの共有をサポートしていないことに注意してください。そのような共有ファイルがある場合、それらの間のリンクは移行中に壊れ、最初は同一のファイルになりますが、各プロジェクトで個別のファイルになります。TFS でこれらのファイルの 1 つを更新しても、他のプロジェクトのコピーには反映されなくなります。
Visual Studio Team Foundation Serverに付属のVSSConverter.exeツールを使用する場合は、移行ツールチームによるこのブログで詳しく説明されているように、 TFS 2008 SP1を最初にインストールする必要があります。これには、多くの改善点が含まれています。
このリリースの主な機能には、次のものがあります。
名前空間の競合の排除。以前、これについて「名前変更の問題」としてブログに書きましたが、名前空間が重複しているファイルを正しく移行するようにコンバーターを修正しました。これは、以前のバージョンのツールを使用しようとするほとんどのユーザーにとって最大の問題点でした。
自動ソリューション再バインド。 この最新バージョンでは、VSソリューションファイルは自動的に9.0バージョンにアップグレードされ、バージョン管理にチェックインされます。以前は、ユーザーはこれを手動で行う必要がありました。
タイムスタンプの不整合の修正。VSSによるクライアントタイムスタンプの使用により、実際に発生したのとは逆の順序でリビジョンが記録される可能性があります。ツールはこの問題を認識し、以前は失敗していた変更の移行を続行します。
改善されたロギング。多くの問題を修正しましたが、より適切で詳細なログを提供することで、問題が発生したユーザーが問題を診断するのに役立ちます。
私たちは現在、私の日常の仕事でこれを行う過程にあります。実際には、約 1 か月で切り替えを行っています。私は移行の主要な部分であり、SourceSafe から脱却する理由の大部分を占めています。移行を支援するために、Visual Studio® Team System 2008 Team Foundation Server と Team Suite VPC Imageを使用しました。とても役に立ちました。すぐに、イメージには完全に機能する TFS インストールが含まれており、遊んでデモを行うことができます。ハンズオン ラボも含まれており、ラボの 1 つは VSS -> TFS 移行ツールを実行しています。MSDN サブスクリプションをお持ちの場合、イメージで遊んだら、次のステップは、サブスクリプションに付属の TFS Small Team エディションをインストールすることです。
注意すべき点の 1 つは、Visual Studio 2008 の最新の Service Pack と .NET Framework がイメージにインストールされていることを確認することです。サービス パックはいくつかの厄介なバグを修正し、システムの使いやすさを確実に向上させました。約 90 以上のプロジェクトを含む非常に大きな SourceSafe データベースがあり、移行ツールが完了するまでに約 32 時間かかりました。最初に、テスト用にソースセーフ データベースのバックアップを作成しました。次に、テスト用のソースセーフ データベースで移行を行いました。その後、TFS でソース ツリーを確認したところ、すべて正常に転送されました。VSS からソース ファイルのすべての履歴を保持できたのはすばらしいことでした。運用開始後も、悪臭を放つ VSS データベースを保持する必要はありません。
段階的に移行を進めています。最初にソース管理を行い、開発者がそれを使用できるようにします。その後、作業項目の追跡機能を使用するために、QA とビジネス アナリストを移行します。
私のアドバイスは、移行を段階的に行うことです。一度にやりすぎないでください。システムを使用する人がトレーニングする時間を与えます。
VSS コンバーターは完璧なソリューションとはほど遠いものです。また、コンバータの 2005 バージョンと 2008SP1 バージョンの間には大きな違いがあります。
たとえば、長期間使用されている VSS DB では、多数のユーザーが VSS に貢献しています。これらのユーザーの多くは、かなり前に組織を離れたため、ドメイン アカウントを持っていません。TFS では VSS ユーザーをドメイン アカウントにマッピングする必要があるため、古いユーザーを単一の「ダミー」ドメイン アカウントにマッピングするか、現在のチーム メンバーにマッピングするかを決定する必要があります。
さらに、VSS Converter 2008 では、これらのドメイン アカウントが有効な TFS アカウントである必要があります。一方、2005 コンバーターはこれを強制しません。
VSS 履歴に重要なフォルダー移動が含まれている場合、この移動の前にすべての履歴が失われる可能性があります。たとえば、フォルダーを新しい場所に移動してから、以前の親を削除すると、すべての履歴が失われます。詳細については、この記事を参照してください: http://msdn.microsoft.com/en-us/library/ms253166.aspx
私が関わったある移行では、6 か月前より前のすべての履歴を失った 10 年前の VSS データベースがありました。これは、6 か月前に行われた大規模な整理が原因でした。
TFS 変換ツール<-- これを使用
私はこのツールをすでに何度か使用していますが、必要に応じて SourceSafe からの変更セットの履歴も付いてくるので、結果はかなり満足のいくものです。
とにかく、このツールを使用すると、常にログのエラーと警告に注意を払い、すべてが正常にビルドされたかどうか、または正常にパスしたかどうかを確認する必要があります。
これを実行する前に、SS で分析も実行することをお勧めします。
それが役に立てば幸い
私はグーグルで検索しましたが、このウォークスルーは良いリファレンスのようで、移行をできるだけ簡単にするのに役立つツール VSSConverter について言及しています。
ただし、1 つお勧めしたいのは、バックアップです。これを行う前に、すべてをバックアップしてください。何か問題が発生した場合は、後悔するより安全であることをお勧めします。
リンクが表示されません。これはアドレスです: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx
以前の同僚であるGuyStarbuckからの良いガイダンスがあります。そのアプローチで追加するもう1つのことは、アプリケーションの編成方法（フォルダーなど）をリファクタリングすることを時間の経過とともに決定した可能性があり、これにより、そうする機会が与えられます。
私は、考えずに無計画にソリューションを整理した状況にあり（アプリケーションの大きな変更は言うまでもなく）、別の方法で整理したいという欲求につながりました。VSSからTFSへの移行は、そうするための大きなチャンスです。
元の質問に関する限り：
そして：この移行は確かに私たちの労働習慣を何らかの方法で修正しなければならないことを意味します。この変更は組織にとって問題になる可能性があると思いますか？1つのサイトで約20人の.net開発者のグループを考えてみてください
私は言うでしょう-はい、あなたの仕事の習慣は変わりますが、もっと良くなるでしょう。
あなたの経験がどのように変化するかについての詳細に関しては、私の別の元同僚（およびチームシステムMVP）のSteve St. Jeanが、VSSからTFSへの違いに関する詳細な記事を書きました。