Visual SourceSafe(VSS)からTeam Foundation Server(TFS) 2010に移行するメモ

　MSが本気でVisual SourceSafe(VSS) 2005からTeam Foundation Server(TFS) 2010に移行して欲しいようで、こちらももう限界という気がしたので、移行してみました。

　その結果、それほど楽ではないことが分かりました。

TFS 2010のインストール §

　SQL Server Expressを使えば簡単ですが、そうではない場合はSQL Serverをインストールする手間そのものが必要です。また、ある程度の知識が必要です。インスタンスとは何か、認証の方法、アカウントの事前用意などです。

　TFSのインストールそのものは簡単です。

VSS側の準備 §

　まず、ここに罠があります。実際に試すとデータベースの形式が古いと怒られました。データベースの作成時期が古いと、旧形式という可能性があります。VSS付属のddupd.exeなどを使用して、バージョンを上げねばなりません。これはコマンドラインツールなので、ddupd [dataフォルダ名]などとして実行します。sourcesafe.iniのあるフォルダではなくdataフォルダを指定します。

更新当て §

　あとから以下のような警告が出てくるので、サポート技術情報 950185のパッチを当てておきます。

VSSConverter は、Visual SourceSafe に推奨される更新プログラムがインストールされ

ていないことを検出しました。最善の結果を得るため、サポート技術情報 950185 に記載されている更新プログラムをインストールしてください。これらの更新プログラムをインストールせずに処理を続行すると、移行中に問題が発生することがあります。更新プログラムをインストールせずに移行を続行しますか (Y/N)?

変換の準備 §

　VSSConverterを使います。これはVisual Studioに含まれているコマンドラインツールです。

　ここでVSSConverterを使って更新すれば良いのですが、そのためにはXML文書を1つ書かねばなりません。SourceとDestinationは適当に直します。パス名はsourcesafe.iniのあるパス。サーバ名は自前のTFSサーバ名です。DefaultCollectionはインストール先のコレクションですがデフォルトで用意される名前なので、そのままでも良いでしょう。

　しかし、これも容易な話ではありませんでした。実は、ネットを検索して出てきたサンプルにはcollection属性がありませんでした。VSSConverter 2010 migration Unable to connect to this Team Foundation Server (WRONG URL)を参考に書き足してやっと動きました。

　このファイルをsettings.xmlというファイル名などで保存します。

　これで、あとは以下のようなコマンドで移行します。(settings.xmlが存在するフォルダをカレントディレクトリとして実行すると仮定。必要ならvssconverterへのパスを補う)

• vssconverter Migrate settings.xml

最後の罠? §

　起動するとVSS管理者パスワードを聞かれますが、分かりませんでした。分からないはずで、設定していなかったようです。Enterだけ押して進むことができました。

　そのあと、やっと作業に取りかかってくれますが、かなり待たされます。スキャンの後に移行が行われますが、これにかなりの時間を要します。

移行後 §

　以下のような感じで使用できます。

1. Visual Studio 2010を開いく
2. 表示→チームエクスプローラでチームエクスプローラを開く
3. チームプロジェクトに接続のアイコンで接続するサーバを指定
4. チームエクスプローラのサーバ/コレクション名を右クリックし、新しいチームプロジェクトを作成
5. 「ソース管理」をクリックしてソース管理エクスプローラを開く
6. ローカルパスを指定しておく
7. Visual Studio 2010内で統合された状態で作業するなら、そのままチームプロジェクトに新しいソリューションを追加していけば良い。Visual Studio 2010内に統合されていなくても、ソース管理エクスプローラ内で個別ファイルのチェックインチェックアウトはできるので、チェックアウト後にローカルパスとして指定したフォルダ内のファイルを編集してチェックインすればよい

補足 §

　シェルブ、アンシェルブという言葉が見えるが、これは正規にチェックインするほどできていないものをチェックインせずに棚上げするもの。一種の終電問題対策とも言える。他は、だいたいVSSにもあったか、容易に想像できる言葉が多い感じ。

感想 §

　ソース管理はいろいろ問題があって、紆余曲折の道を辿ってきました。今回追加したツリーの一部は、なんとMicrosoft DeltaからSourceSafeにコンバートして移行したファイルです。それ以前にもMSKK社員時代にDeltaの原型を使っていますが、もちろん当時のソースツリーを社外に持ち出せるはずもなく、後から試しに使ったRCSも実質的にあまりに使えなくて放棄したので資産としてはDelta時代が最古になりますかねえ。しかし、SourceSafeへのコンバータが英語版しか提供されず、全部英語でコメントも入れてあって良かったと思いつつ移行したのもかなり昔です。これでも、Deltaのベータテスターに応募して使っていたのですよ。って、今時の若い人はDeltaの名前も知らないでしょうが。Deltaを放棄してMSがSourceSafeを買ったのも驚きましたが、SourceSafeの高機能さにも驚きました。それもかなり昔の話。

　ちなみに余談をさらに書くと。結局、SourceSafeから離れたのはデータベースが壊れやすいからです。以下の3つのケースでデータベースが壊れやすい感じです。

• 複数ユーザーが同時に作業するとき
• ネットワークの接続が一時的に切断されたとき
• SourceSafeファイル処理中のVisual Studioのハング

　複数ユーザーが同時に作業するとき、というのは1人で使っているとあり得ない事態ででしたが、LANブースターを使うと1人でも発生してしまいました。サーバ上のLANブースターと、直接ファイル共有でアクセスするクライアント側からのアクセスで実質的に2ユーザーのアクセスになってしまいました。LANブースターが提供されない初期にはあり得なかった事態です。

　それから、ネットワークの接続が一時的に切断されるケースがなぜか増えています。何の関係かはまだ調べ切れていません。

　Visual Studioのハングもしばしば起こっています。Visual Studio 2008がおかしくなることはしばしばありますが、これも原因が分かっていません。

　というわけで、ファイル共有ベースのSourceSafeはそろそろ終わる時期かなと思ったので、全面的にTFSに移行してSourceSafeのデータベースは残さない方針で進めてみました。ちなみに、開発者が明確にSourceSafeの後継がTFSとして作っていることを示していることを知ったことも後押しになっているかも。心理的に。

　試しにVisual Studioで管理していないWebのページも更新してみましたが、問題なくできました。

　とりあえず、もうちょっと使ってみましょう。