Visual SourceSafe からの移行
Team Foundation VSSConverter のコマンド ライン ツールを使用すると、プロジェクト、ファイル、バージョン履歴、ラベル、およびユーザー情報を Visual SourceSafe データベースから Team Foundation バージョン管理サーバーに移行できます。 このツールは Visual Studio Team Foundation Server に付属しています。
Visual SourceSafe の詳細については、Microsoft Web サイトの「Visual SourceSafe ドキュメント」を参照してください。
Visual SourceSafe データベースからデータを移行するには
主要な概念について理解する。データを Visual SourceSafe データベースから Team Foundation バージョン管理サーバーに移行する前に、いくつかの重要な概念について理解しておく必要があります。 Team Foundation と Visual SourceSafe には機能面での大きな違いがあります。 その結果、データの種類によっては、移行時に VSSConverter による編集が必要となります。
詳細については、このトピックで後述する「VSSConverter によるデータの変換」を参照してください。
**必要なアクセス許可が付与されていることを確認する。**このトピックの各手順を実行するには、いくつかの種類のアクセス許可が必要となります。 詳細については、このトピックで後述する「必要なアクセス許可」を参照してください。
**移行プロセスを計画および準備する。**移行プロセスを開始する前に、計画と準備のための手順を実行することによって重大な問題を防ぐことができます。 詳細については、このトピックで後述する「移行プロセスの計画と準備」を参照してください。
**データを分析する。**Visual SourceSafe から Team Foundation バージョン管理にデータを移行する前に、まず Visual SourceSafe コンバーターの分析機能を使用して、データ内の懸案事項が移行の成果に影響を及ぼすかどうかを判断する必要があります。 このプロセスでは、データを移行するために必要なユーザー マップ ファイルも生成されます。 詳細については、このトピックで後述する「データの分析」を参照してください。
**データを移行する。**分析機能を実行したら、データを移行する準備はほぼ完了です。 データを移行するには、ユーザー名の移行方法を指定し、移行用の設定ファイルを作成して、Migrate コマンドを実行する必要があります。 詳細については、このトピックで後述する「データの移行」を参照してください。
**移行を検証して懸案事項を解決する。**移行機能が完了したら、次の手順を実行する必要があります。
移行機能によって生成されたレポートをレビューします。
Team Foundation バージョン管理サーバー上のデータをチェックして、Visual SourceSafe データベースからのデータが正しく移行されていることを確認します。
これらの手順を実行した後で、問題のトラブルシューティングが必要となる場合があります。 詳細については、このトピックで後述する「移行の検証と懸案事項の解決」を参照してください。
必要なアクセス許可
このトピックの各手順を実行するには、次のアクセス許可が必要です。
移行するデータが格納されている Visual SourceSafe データベースに対する Admin アカウントのパスワードを知っている必要があります。
移行マシン (Visual Studio がインストールされているコンピューター) に対する Administrators グループのメンバーである必要があります。
VSSConverter によって使用されるデータベースに対する "データベースの作成" アクセス許可が必要です。 詳細については、このトピックで後述する「VSSConverter によって使用されるデータベースの提供」を参照してください。
Team Foundation のアプリケーション層に対する Team Foundation 管理者セキュリティ グループのメンバーである必要があります。 詳細については、「Team Foundation Server のアクセス許可」を参照してください。
移行プロセスの計画と準備
移行プロセスを開始する前に、計画と準備のための手順を実行することによって重大な問題を防ぐことができます。
所要時間を短縮するためのオプションを検討する
コンバーターには、移行時間を短縮するか、移行中にもチームがバージョン管理を操作できるようにすることにより、移行に消費される時間を最小限に抑えることができる移行オプションが用意されています。 次に示す移行オプションのうち、チームに最も適したオプションを判断してください。
選択したプロジェクトを移行する: Visual SourceSafe データベース全体を一度にまとめて移行する代わりに、選択したプロジェクトを複数回に分けて移行できます。 詳細については、このトピックで後述する「<ProjectMap> セクション」を参照してください。
履歴データの一部を切り捨てる: Visual SourceSafe のアーカイブ機能を使用して履歴の一部を移行できます。 古い履歴を移行する必要がない場合は、このオプションを使用してください。 この機能を使用すると、ファイルおよびフォルダーの特定の日付以前のバージョン履歴が削除されます。 詳細については、このトピックで後述する「項目の履歴の切り捨て」を参照してください。
移行のスケジュールをチームで設定する
移行対象の Visual SourceSafe データベースにユーザーがアクセスする必要がない時間帯に移行をスケジュールします。 データ量やチームの人数が多い場合、またはプロジェクトの期間が長い場合は、データの準備と移行に長時間かかる可能性があることを見越しておく必要があります。
重要
移行プロセスが行われる時間帯をチーム メンバーに知らせて、プロセスが開始する前にすべてのファイルをチェックインしておくように忠告します。
Visual SourceSafe データベースのコピーと準備
次の手順に従って、Visual SourceSafe データベースのコピーと準備を行います。
ファイルをチェックインする。 Visual SourceSafe データベース内のすべてのファイルをチェックインするのが理想的です。 少なくとも、できる限り多くのファイルをチェックインするようにしてください。
Visual SourceSafe プロジェクトへのアクセスを削除する。 移行対象の Visual SourceSafe プロジェクトに自分しかアクセスできないことを確認します。
データベースをコピーする。 Microsoft Web サイトの「Visual SourceSafe データベースをバックアップする方法」に示されている手順に従います。
データベースのコピーをアップグレードする。 Visual SourceSafe データベースが Visual SourceSafe 6.0 よりも前のバージョンの場合は、Visual SourceSafe DDUPD ユーティリティを使用して Visual SourceSafe 2005 にアップグレードします。 詳細については、Microsoft Web サイトの「DDUPD ユーティリティ」を参照してください。
(省略可能) 項目の履歴を切り捨てる。 詳細については、このトピックで後述する「項目の履歴の切り捨て」を参照してください。
データベースのコピー内でデータ整合性の懸案事項を調べて修正する。 Visual SourceSafe ANALYZE ユーティリティを使用して、データベース内のデータ整合性の懸案事項を検出し、修正します。 このツールの使用方法の詳細については、Microsoft Web サイトの「ANALYZE ユーティリティ」および「How to Detect and Fix Database Corruption Errors in Visual SourceSafe (Visual SourceSafe データベース破損エラーを検出して修正する方法)」を参照してください。
項目の履歴の切り捨て
Visual SourceSafe に格納されている履歴を全部移行する必要があるわけではない場合は、Visual SourceSafe のアーカイブ機能を使用して、特定の日付以降の履歴のみを移行できます。
ヒント
この方法を使用すると、Visual SourceSafe データベースのバージョン履歴が完全に削除されます。そのため、実行中の Visual SourceSafe データベースではなく、データベースのコピーに対してこの手順を実行するようにしてください。
Visual SourceSafe で項目の履歴を切り捨てるには、Visual SourceSafe のアーカイブ機能を使用します。 次のいずれかの値をタイム スタンプとして使用して、その値以前の履歴を切り捨てるように指定できます。
Label
フォルダーのバージョン
日付
Visual SourceSafe でアーカイブを実行する方法の詳細については、「データベースのアーカイブ」を参照してください。
注意
Visual SourceSafe のアーカイブ機能では、アーカイブ ファイルのサイズを 2 GB 以下にする必要があります。 アーカイブの実行中にエラーが発生する場合は、プロジェクトを細分して別々にアーカイブしてください。
移行マシンを準備する
次の手順に従って移行マシンを準備します。
移行プロセスを実行するのに十分な空きディスク容量がマシンにあることを確認します。 必要なディスク容量を見積もるには、次の項目の合計を算出します。
VSSConverter が一次ファイルの作成とログ ファイルの生成に使用できる 5 GB のディスク容量。
移行する Visual SourceSafe データベース内のプロジェクトのサイズの 2 倍に相当するディスク容量。
次の手順で説明するアプリケーションをインストールするのに十分なディスク容量。
移行マシンに Visual Studio をインストールします。
重要
VSSConverter が機能するためには、データベース (SQL Server Express または SQL Server) が必要となります。 既定では、Visual Studio をインストールすると、SQL Server Express がインストールされ、VSSConverter を機能させるために必要なアクセス許可が与えられます。 詳細については、このトピックで後述する「VSSConverter によって使用されるデータベースの提供」を参照してください。
移行マシンに Visual SourceSafe 2005 をインストールします。
Microsoft サポート技術情報の文書 950185 に関連した更新プログラムをインストールします。 このソフトウェアは、Microsoft Web サイトの「KB950185 - VSS Required QFE for Orcas SP1 VSSConverter」から入手できます。
「Visual SourceSafe データベースのコピーと準備」の手順に従ったことを確認します。
Visual SourceSafe データベースを移行マシン上のフォルダーにコピーします。
ヒント
データベースをコピーする代わりに、ファイル共有を使用して移行マシンが Visual SourceSafe データベース内のデータにアクセスできるようにする場合は、移行マシンにログオンするときに使用するアカウントに読み取りと変更のアクセス権を付与する必要があります。このアプローチは移行プロセスを長引かせる可能性があるため、推奨されません。
重要
移行マシンによる Visual SourceSafe データベースへのアクセスをどのように設定するかにかかわらず、実行中のデータベースではなく、データベースのコピーに対して移行プロセスを実行してください。 このアプローチはデータの保護に役立ちます。
VSSConverter によって使用されるデータベースの提供
VSSConverter が機能するためには、データベース (SQL Server Express または SQL Server) が必要となります。 既定では、Visual Studio のインストール時に、SQL Server Express がインストールされます。 Visual Studio のインストール時にこのオプションを選択解除する場合は、SQL Server Express を後で手動でインストールするか、SQL Server をデータベースとして使用する必要があります。
どちらのデータベースを使用するかにかかわらず、データベースに対する "データベースの作成" アクセス許可が必要です。 SQL Server Express を Visual Studio と共にインストールした場合は、このアクセス許可が自動的に付与されます。
SQL Server Express の代わりに SQL Server を使用するには、設定ファイルを変更する必要があります。 詳細については、このトピックで後述する「<SQL> 要素」を参照してください。
Team Foundation Server のインスタンスの準備
次の手順に従って移行マシンを準備します。
Team Foundation のデータ層に利用可能な記憶域が十分にあることを確認します。 通常は、移行する Visual SourceSafe データベースに格納されているプロジェクトのデータ サイズを約 2 倍した容量が必要となります。
必要な容量は次の要因によって左右される場合があります。
移行する Visual SourceSafe データベースのサイズ
移行するアクションの数
移行機能を使用して移行プロセスを開始するには、チーム プロジェクト コレクションとチーム プロジェクトが Team Foundation バージョン管理サーバー上に既に存在していることが必要です。 Visual SourceSafe データの移行先にするチーム プロジェクト コレクションまたはチーム プロジェクトがまだない場合は、次の手順のいずれかまたは両方を実行します。
Visual SourceSafe データベースからのデータの移行先にするチーム プロジェクト コレクションを作成します。 詳細については、「チーム プロジェクト コレクションの作成」を参照してください。
Visual SourceSafe データベースからのデータの移行先にする 1 つまたは複数のチーム プロジェクトを作成します。 詳細については、「チーム プロジェクトの作成」を参照してください。
データの分析
Visual SourceSafe から Team Foundation バージョン管理 にデータを移行する前に、まず Visual SourceSafe コンバーターの分析機能を使用して、データ内の懸案事項が移行の成果に影響を及ぼすかどうかを判断する必要があります。 この機能では、移行機能がデータを移行するために使用するユーザー マップ ファイルも生成されます。
分析用の設定ファイルの作成
分析機能を使用するには、設定ファイルを作成する必要があります。 このファイルでは、移行する Visual SourceSafe データベースのパスと移行先フォルダーを指定します。
次の XML は分析用の設定ファイルの例です。
<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name="VSS">
<VSSDatabase name="c:\ourvss"></VSSDatabase>
<UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
</Source>
<ProjectMap>
<Project Source="$/Core"></Project>
<Project Source="$/ProjectA"></Project>
<Project Source="$/ProjectB"></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settings>
<Output file="c:\ourvss\migrate\logs\ContosoVSSAnalyze.xml"></Output>
</Settings>
</SourceControlConverter>
このサンプル ファイルをコピーして独自の設定ファイルに貼り付け、カスタマイズすることが可能です。 次の情報を使用して、サンプル ファイルをニーズに合わせてカスタマイズできます。
<?xml encoding> 属性
<?xml encoding> 属性は、設定ファイルで使用されるエンコーディングと一致している必要があります。 たとえば、ファイルが Unicode として保存される場合、<?xml encoding> タグは次のようになります。
<?xml version="1.0" encoding="unicode">
<VSSDatabase name> 属性
<VSSDatabase name> 属性では、移行する Visual SourceSafe データベースのコピー用の srcsafe.ini ファイルが保存されているフォルダーのパスを指定します。以下にコードの例を示します。
<Source name="VSS">
...
<VSSDatabase name="c:\ourvss"></VSSDatabase>
...
</Source>
パスに文字列 srcsafe.ini を含めることはできません。 たとえば、次の <VSSDatabase name> 属性は間違いであり、VSSConverter コマンドが失敗する原因となります。
<Source name="VSS">
...
<VSSDatabase name="c:\ourvss\srcsafe.ini"></VSSDatabase>
...
</Source>
<UserMap name> 属性
分析機能は、Visual SourceSafe ユーザーに関するデータを収集してコンパイルし、XML ファイルに格納します。 必要に応じて、このデータの格納先ファイルのパスと名前を <UserMap name> 属性で指定することもできます。 この属性を指定しないと、分析機能によって UserMap.xml という名前のファイルが作成され、現在のディレクトリに配置されます。
<ProjectMap> セクション
<ProjectMap> セクションでは、<Project> 項目の Source 属性を使用して、移行対象の各 Visual SourceSafe プロジェクトのパスを指定します。
Visual SourceSafe データベース内のすべてのデータを移行するには、<ProjectMap> セクションを次の例と一致させます。
<ProjectMap>
<Project From="$/"></Project>
</ProjectMap>
Visual SourceSafe データベース全体を一度にまとめて移行する代わりに、選択したプロジェクトを複数回に分けて移行できます。 このオプションを使用すると、大量のデータを移行する必要がある場合に、移行作業でチームの手がふさがるのを防ぐことができます。
Source 属性のパスを重複させることはできません。 たとえば、次の <ProjectMap> セクションは無効です。
<ProjectMap>
<Project Source="$/ProjectA"></Project>
<Project Source="$/ProjectA/Controller"></Project>
</ProjectMap>
<Output file> 属性
<Settings> セクションでは、<Output file> 属性を使用して、分析レポートを書き込むファイルのパスと名前を指定できます。 この属性を指定しないと、コンバーターによって VSSAnalysisReport.xml という名前のファイルにレポートが書き込まれ、現在のディレクトリに配置されます。
<SQL> 要素
SQL Server Express の代わりに SQL Server を使用するようコンバーターに指示するには、移行用の設定ファイルの <Source> セクションに <SQL> 要素を追加します。 この要素は <SQL Server="SQL_Server_name"></SQL> という構文を使用します。
たとえば、次の <SQL> 要素は、サーバーが "ContosoSQLServer" であることを示しています。
<Source name="VSS">
...
<SQL Server="ContosoSQLServer"></SQL>
...
</Source>
分析コマンドの実行
コンバーターを使用してプロジェクトを分析するには
[スタート] ボタンをクリックして [すべてのプログラム] をポイントし、[Microsoft Visual Studio 2010] をポイントします。次に [Visual Studio Tools] をポイントして [Visual Studio 10.0 コマンド プロンプト] を右クリックし、[管理者として実行] をクリックします。
[ユーザー アカウント制御] ダイアログ ボックスが表示されたら、[続行] をクリックします。
次のコマンド ラインを入力します。
VSSConverter Analyze settings.xml
作成した分析用設定ファイルのパスと名前で settings.xml を置換します。
メッセージが表示されたら、Visual SourceSafe の管理者パスワードを入力します。
VSSConverter により分析機能の進行状況が表示されます。 処理が完了すると、分析機能によってレポートとユーザー マップ ファイルが生成されます。
分析機能によって検出された懸案事項のレビューと解決
分析レポートには、移行時に問題を招く可能性のある Visual SourceSafe データベース内の懸案事項に関する情報が示されます。 次のセクションで説明する移行時の問題を最小限にとどめるには、できる限り多くの懸案事項を解決しておくことが重要です。
一部のファイルがチェックアウトされている
分析レポートには、現在チェックアウトされているファイルが表示されます。 移行プロセスでは、チェックアウト情報は保存されません。 Visual SourceSafe データベース内のすべてのファイルをチェックインするのが理想的です。 少なくとも、できる限り多くのファイルをチェックインするようにしてください。
一部の項目にデータ整合性の懸案事項がある
分析レポートには、データの整合性が損なわれている項目が示されます。 これらの項目は移行されません。 Visual SourceSafe の ANALYZE ユーティリティを使用すると、この種の懸案事項を解決できる可能性があります。 詳細については、Microsoft Web サイトの「ANALYZE ユーティリティ」および「How to Detect and Fix Database Corruption Errors in Visual SourceSafe (Visual SourceSafe データベースで破損エラーを検出して修正する方法)」を参照してください。
<ProjectMap> セクションにない履歴がマップ済みプロジェクト内の一部のフォルダーに含まれている
Visual SourceSafe データベース内のプロジェクト間でフォルダーを移動した場合、そのフォルダーの履歴は元のプロジェクトと現在のプロジェクトの両方に格納されます。 これらのフォルダーをそのすべての履歴と共に移行するには、元のプロジェクトと現在のプロジェクトの両方を移行する必要があります。
たとえば、Visual SourceSafe のプロジェクトである Project2 を移行しているとします。 このプロジェクトには、その履歴のある時点で Project1 から移動された $/Project2/FeatureA というフォルダーが含まれています。
<ProjectMap> セクションの内容 |
例 |
結果 |
|---|---|---|
両方のプロジェクト。 |
|
フォルダーはその全履歴と共に移行されます。 |
フォルダーを現在含んでいるプロジェクトではなく、最初にフォルダーを含んでいたプロジェクト。 |
|
フォルダーは移行されません。 |
最初にフォルダーを含んでいたプロジェクトではなく、フォルダーを現在含んでいるプロジェクト。 |
|
フォルダーは、そのフォルダーを現在のプロジェクトに移動した後で生じた履歴と共に移行されます。 フォルダーを現在のプロジェクトに移動する前に生じた履歴は移行されません。 |
設定ファイルの <ProjectMap> セクションの詳細については、このトピックで前述した「<ProjectMap> セクション」を参照してください。
一部のラベル名が Team Foundation バージョン管理によってサポートされていない
分析レポートには、Team Foundation バージョン管理によってサポートされていない文字が含まれているために移行時に変更されるラベル名が示されます。
データの移行
分析機能を実行したら、データを移行する準備はほぼ完了です。 Migrate コマンドを実行する前に、移行用の設定ファイルを作成しておく必要があります。 必要に応じて、ユーザー名の移行方法を指定することもできます。
ユーザー名の移行方法の指定
ユーザー情報を Visual SourceSafe から Team Foundation バージョン管理にどのように移行するかを制御できます。 具体的には、移行機能を使用してどのユーザー名を Team Foundation バージョン管理内の各項目の履歴の変更セットと関連付けるかを指定できます。 これを行うには、分析機能を実行したときに作成されたユーザー マップ ファイルを、このトピックで前述したように編集します。
ユーザー マップ ファイルは省略可能です。 <UserMap> 要素を設定ファイルから省略した場合、各変更セットは次のように構築されます。
User フィールドは、VSSConverter の実行に使用しているアカウントの名前に設定されます。
Visual SourceSafe データベースでアクションを実行したユーザーの名前は Comment フィールドに格納されます。
ユーザー マップ ファイルの例
分析機能を実行すると、Visual SourceSafe ユーザーに関するデータがコンパイルされて、XML ファイルに格納されます。 このファイルには、移行対象の Visual SourceSafe プロジェクトでバージョン管理操作を行ったことがある Visual SourceSafe ユーザーがすべて示されます。
次の例は、Visual SourceSafe コンバーターの分析機能によって作成されたユーザー マップ ファイルを示しています。
<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
<UserMap From="Admin" To=""></UserMap>
<UserMap From="Guest" To=""></UserMap>
<UserMap From="Kim" To=""></UserMap>
<UserMap From="Satomi" To=""></UserMap>
<UserMap From="Mark" To=""></UserMap>
</UserMappings>
ユーザー マップ ファイル内の UserMap 項目の To 属性は一切指定しないか、一部または全部の項目に対して指定できます。 たとえば、前の例は次のように変更できます。
<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
<UserMap From="Admin" To="NORTHAMERICA\KenM"></UserMap>
<UserMap From="Guest" To="Test1"></UserMap>
<UserMap From="Kim" To="EUROPE\KimT"></UserMap>
<UserMap From="Satomi" To="ASIA\SatomiH"></UserMap>
<UserMap From="Mark" To=""></UserMap>
</UserMappings>
前の例では、Guest は Test1 にマップされ、ドメインは指定されていません。 このような場合、VSSConverter ではアカウントが既定のドメインに所属するものと仮定されます。
<UserMap To> 属性を指定しない場合、各変更セットは次のように構築されます。
User フィールドは、VSSConverter の実行に使用したアカウントの名前に設定されます。
Visual SourceSafe データベースでアクションを実行したユーザーの名前は Comment フィールドに格納されます。
<UserMap To> 属性を指定しており、その値が Team Foundation を実行しているサーバー上の有効なユーザーである場合、User フィールドはそのアカウントの名前に設定されます。 属性の値が Team Foundation を実行しているサーバー上の有効なユーザーでない場合、VSSConverter はエラーを表示し、移行プロセスを終了します。
移行用の設定ファイルの作成
移行対象の Visual SourceSafe データを指定し、移行方法のさまざまな側面を制御するには、移行用の設定ファイルを使用します。 このファイルを作成する方法として最も簡単なのは、このトピックで前述した「分析用の設定ファイルの作成」で作成したファイルをコピーすることです。 次に、このファイルにデータを追加して移行機能で使用できるようにします。
次の例は移行用の設定ファイルを示しています。
<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
<Source name="VSS">
<VSSDatabase name="c:\ourvss"></VSSDatabase>
<UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
</Source>
<ProjectMap>
<Project Source="$/Core" Destination="$/CoreTeamProject"></Project>
<Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
<Project Source="$/ProjectB" Destination="$/ClientTeamProject/ProjectB"></Project>
</ProjectMap>
</ConverterSpecificSetting>
<Settings>
<TeamFoundationServer name="My_Server" port="8080" protocol="http" collection="tfs/DefaultCollection"></TeamFoundationServer>
<Output file="c:\ourvss\migrate\logs\ContosoVSSMigrate.xml"></Output>
</Settings>
</SourceControlConverter>
次の情報を使用して設定ファイルを編集すると、移行機能によるデータの移行方法を指定できます。
<Project Destination> 属性
設定ファイルの <ProjectMap> セクションの <Project> 要素ごとに Destination 属性を使用して、(Source 属性で指定されている) Visual SourceSafe データベース内のプロジェクトの内容を移行する Team Foundation バージョン管理サーバー上の場所のパスを指定します。
たとえば、Visual SourceSafe データベース内の ProjectA の内容を Client というチーム プロジェクトのルートにある ProjectA に移行するとします。
<ProjectMap>
<Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
</ProjectMap>
Destination 属性の値が有効であるためには、次の条件が満たされている必要があります。
移行プロセスを開始する前に、Destination 属性のチーム プロジェクト (前の例では ClientTeamProject) がチーム プロジェクト コレクションに既に含まれている必要があります。
Destination 属性内のフォルダー (前の例では ProjectA) がチーム プロジェクトに既に含まれている場合は、フォルダーが空であることが必要です。
<Project> 要素の Destination 属性内のパスは、他のどの <Project> 要素の Destination 属性内のパスとも重複させることができません。 たとえば、次の <ProjectMap> セクションは無効です。
<ProjectMap> <Project Source="$/ProjectA" Destination="$/ClientTeamProjectA/"></Project> <Project Source="$/ProjectB" Destination="$/ClientTeamProjectA/ProjectB"></Project> </ProjectMap>
<TeamFoundationServer> タグ
<Settings> セクションでは、<TeamFoundationServer> タグを追加して、Team Foundation Server を実行しているサーバー上のチーム プロジェクト コレクションの名前、ポート、プロトコル、およびパスを次の形式で指定します。
<TeamFoundationServer name="ServerName" port="PortNumber" protocol="http" collection="path/collection name></TeamFoundationServer>
<Label migrate="false" /> タグ
使用する Visual SourceSafe データベースに多数のファイルに適用される多数のラベルが含まれている場合は、移行プロセスが長引く可能性があります。 このデータがチームに不要な場合は、<Label migrate="false" /> タグを <Settings> セクションに追加することによって、ラベルを無視するように VSSConverter を設定できます。
<Output file> 属性
<Settings> セクションでは、<Output file> 属性を使用して、移行レポートを書き込むパスとファイルを指定できます。 この属性を指定しないと、コンバーターによって VSSMigrationReport.xml という名前のファイルにレポートが書き込まれ、現在のディレクトリに配置されます。
Migrate コマンドの実行
Migrate コマンドを実行するには
[スタート] ボタンをクリックして [すべてのプログラム] をポイントし、[Microsoft Visual Studio 2010] をポイントします。次に [Visual Studio Tools] をポイントして [Visual Studio 10.0 コマンド プロンプト] を右クリックし、[管理者として実行] をクリックします。
[ユーザー アカウント制御] ダイアログ ボックスが表示されたら、[続行] をクリックします。
コマンド プロンプトに次のコマンド ラインを入力します。
VSSConverter Migrate settings.xml
作成した移行用設定ファイルのパスと名前で settings.xml を置換します。
Visual SourceSafe データベースから移行しようとしているプロジェクトと Team Foundation バージョン管理 サーバー上のデータの移行先フォルダーがそれぞれ移行機能によって表示されます。
移行を確認するメッセージが表示されたら、Y キーを押します。
プロンプトが表示されたら、Visual SourceSafe データベースの管理者ユーザーのパスワードを入力します。
プロセスの実行中、移行機能の現在のステータスはコマンド プロンプト ウィンドウに表示されます。
段階的な移行を使用したプロセスの再開
移行プロセスがなんらかの理由で中断した場合は、終了した時点から段階的な移行としてプロセスを再開できます。 段階的な移行は、エラーまたはネットワークの問題が原因で移行プロセスが失敗した場合に役立ちます。 段階的な移行では、前のセッションで移行されなかったデータだけがコンバーターによって移行されます。
段階的な移行を開始するには、「Migrate コマンドの実行」の手順に従います。 段階的な移行の実行を確認するプロンプトが表示されたら、Y キーを押します。
段階的な移行に関する制限事項
次の制限事項に従わないと、段階的な移行は成功しません。
Visual SourceSafe データベースでは破棄、削除、アーカイブ、または復元の動作を実行しないでください。
移行用設定ファイルの <ProjectMap> セクションを変更しないでください。
Team Foundation バージョン管理サーバー上では、移行用設定ファイルの <ProjectMap> セクションで指定されているフォルダー (またはフォルダーの内容) を変更しないでください。
移行の検証と懸案事項の解決
移行機能が完了したら、次の手順を実行する必要があります。
移行機能によって生成されたレポートをレビューします。
Team Foundation バージョン管理サーバー上のデータをチェックして、データが正しく移行されていることを確認します。
これらの手順を実行した後で、問題のトラブルシューティングが必要となる場合があります。
SQL Server Express のストレージ制限を超える問題の解決方法
VSSConverter では、一時メタデータの格納に SQL Server Express が既定で使用されます。 通常、このメタデータは、移行するデータの合計サイズのうち小さな割合を占めます。 めったにないことですが、SQL Server Express の 4 GB の制限に達したために移行が失敗する場合は、SQL Server を代わりに配置するようコンバーターに指定する設定を適用できます。 詳細については、このトピックで前述した「<SQL> 要素」を参照してください。
MS-DOS 互換の短い名前 (8.3) 形式のファイルの変換 (TF227014)
Team Foundation バージョン管理では、MS-DOS 互換の短い名前 (8.3) 形式のファイル名 (たとえば abcdef~1.txt) を使用できません。 このような名前のファイルを分析したり、移行しようとしたりすると、TF227014 エラーが表示されます。
そのような名前のファイルを使用できるようにする設定を Team Foundation のアプリケーション層に一時的に適用すると、この懸案事項を回避できます。 これを行うには、Team Foundation の構成データベースで Allow8Dot3Paths を True に設定する必要があります。
重要
MS-DOS 互換の短い名前をサポートしているクライアント マシンで懸案事項が生じるのを防ぐため、移行プロセスが完了した後で、次の手順に示すように Allow8Dot3Paths を False に設定することを強くお勧めします。
次の手順を実行するには、Windows PowerShell が Team Foundation のアプリケーション層サーバーで有効になっている必要があります。 詳細については、Microsoft Web サイトの「Windows PowerShell でのスクリプティング」を参照してください。
必要なアクセス許可
この手順を実行するには、Team Foundation のアプリケーション層サーバーで管理者グループのメンバーである必要があります。 詳細については、「Team Foundation Server のアクセス許可」を参照してください。
MS-DOS 互換の短い名前形式のファイルが格納されている Visual SourceSafe データベースを移行するには
Team Foundation のアプリケーション層サーバーにログオンします。
Allow8Dot3Paths という名前の Windows PowerShell スクリプトを作成します。
「Allow8Dot3Paths PowerShell スクリプト」のテキストをコピーして、このスクリプトに貼り付けます。
Team Foundation Server への接続に使用する URL のパスと一致するように ServerPath を変更します。 既定のサーバー パスは "tfs" です。
データの移行先にするチーム プロジェクト コレクションの名前 (たとえば DefaultCollection) と一致するように CollectionName を変更します。
たとえば、結果はスクリプト内の次のような行になります。
$collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";
Allow8Dot3Paths スクリプトを実行します。
Team Foundation のアプリケーション プールをリサイクルします。
[スタート] ボタンをクリックし、[管理ツール] をクリックして、[コンピューターの管理] をクリックします。
ナビゲーション ウィンドウで、[サービスとアプリケーション] を展開します。
[インターネット インフォメーション サービス (IIS) マネージャー] をクリックして、ローカル コンピューターを展開し、[アプリケーション プール] をダブルクリックします。
アプリケーション プールを右クリックして [リサイクル] をクリックします。
Migration コマンドを実行します。
詳細については、「Migrate コマンドの実行」を参照してください。
前の手順で作成した Allow8Dot3Paths Windows PowerShell スクリプトの "true" を "false" で置換します。
変更した Allow8Dot3Paths スクリプトを実行します。
Team Foundation のアプリケーション プールをリサイクルします。
[スタート] ボタンをクリックし、[管理ツール] をクリックして、[コンピューターの管理] をクリックします。
ナビゲーション ウィンドウで、[サービスとアプリケーション] を展開します。
[インターネット インフォメーション サービス (IIS) マネージャー] をクリックして、ローカル コンピューターを展開し、[アプリケーション プール] をダブルクリックします。
アプリケーション プールを右クリックして [リサイクル] をクリックします。
チーム エクスプローラーを開き、データの移行先に指定したチーム プロジェクト コレクションに接続します。
ソース管理エクスプローラーで、MS-DOS 互換の短い名前 (8.3) 形式のファイル名をすべて変更します。
Allow8Dot3Paths PowerShell スクリプト
# Load client OM assembly.
[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
$collectionBaseUrl = "https://localhost:8080/ServerPath/CollectionName/";
$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);
# Set some version control settings in the collection hive.
$collectionHive.SetValue("/Service/VersionControl/Settings/Allow8Dot3Paths", "True");
# Display all version control settings as a table.
$collectionHive.ReadEntries("/Service/VersionControl/Settings/...") | ft -a
VSSConverter によるデータの変換
Team Foundation と Visual SourceSafe には機能面での大きな違いがあります。 その結果、データの種類によっては、移行時に VSSConverter による編集が必要となります。
変更セット
Team Foundation バージョン管理の主要機能の 1 つは、ユーザーによって変更のセットがチェックインされたときに複数のファイルへの変更を 1 つの単位にまとめる機能です。 この 1 つの単位のことを変更セットと呼びます。
Visual SourceSafe には、変更セットに相当する機能がありません。 ただし、次の条件が満たされている場合は、変更プロセスの実行中に変更の各セットが変更セットにまとめられます。
変更が互いに競合していない。 たとえば、同じファイルまたはフォルダーに対して 2 つの操作が実行されることはありません。
変更が数分以内の間隔で起きている。
変更が同一ユーザーによってチェックインされている。
変更のチェックイン コメントが同じである。
詳細については、「変更セットの操作」を参照してください。
共有と固定
Visual SourceSafe では、1 つのファイルを複数のフォルダー間で共有できます。 共有ファイルに対して行った変更は、それを共有している各フォルダーにレプリケートされます。 Team Foundation バージョン管理 には、これと同等の機能がありません。 移行時に、Visual SourceSafe プロジェクト内の共有ファイルは、Team Foundation バージョン管理サーバー上の項目の追加的な独立コピーを作成することによって移行されます。
Team Foundation バージョン管理には、Visual SourceSafe の固定機能に相当する機能がありません。 移行時に、Visual SourceSafe プロジェクト内の固定された項目は、Team Foundation バージョン管理サーバー上のラベル付けされた項目に変換されます。 詳細については、次のセクションを参照してください。
Team Foundation バージョン管理のラベルの詳細については、「ラベルを使用したファイルのスナップショット取得」を参照してください。
履歴データ
Visual SourceSafe データベース内の項目の履歴に含まれている各イベントは、変更セットとして Team Foundation バージョン管理サーバーに転送されます。 移行プロセスが完了したら、このデータを [履歴] ウィンドウで表示できます。 詳細については、「[履歴] ウィンドウの使用」を参照してください。
データに対する変更は移行時に生じる場合もあります。
ユーザー名と日付時刻スタンプに関するデータの移行方法
Visual SourceSafe データベース内の項目の履歴に含まれている各エントリが Team Foundation バージョン管理サーバーの変更セットに移行されると、次の変更が生じます。
変更セットの日付時刻スタンプは、項目が移行されたときの日付と時刻に設定されます。
元の日付時刻スタンプは変更セットの Comment フィールドに格納されます。
ユーザー名は、ユーザー マップ プロセスの結果に応じて、変更セットの User フィールドまたは Comment フィールドのいずれかに格納されます。 詳細については、このトピックで前述した「ユーザー名の移行方法の指定」を参照してください。
特定の種類のイベントの変換方法
編集、名前変更、削除などのイベントは、Visual SourceSafe データベースから Team Foundation バージョン管理サーバー上の変更セットに単純に移行されます。 ただし、イベントによっては、次の表に示すような予想外の方法で VSSConverter によって移行される場合があります。
Visual SourceSafe イベント |
Team Foundation への移行方法 |
|---|---|
ファイルまたはフォルダーの追加 |
この変更セットは、移行される各ファイルとフォルダーの履歴における最初のイベントです。 Visual SourceSafe と異なり、各子項目の親に関するイベントは記録されません。 |
分岐 |
共有は Visual SourceSafe における分岐の前提条件ですが、Team Foundation バージョン管理 では共有がサポートされていません。そのため、分岐したファイルを移行すると、このファイルのコピーが移行先フォルダーに作成されます。 Visual SourceSafe データベース内の共有ファイルは、共有時に存在していたファイルのバージョンをコピーし、コピーを移行先フォルダーに配置することによって Team Foundation バージョン管理に移行されます。 その後、各変更セットは、分岐イベントが発生するまで共有ファイルの両方のコピーにレプリケートされます。 |
ファイルのラベル付け |
Team Foundation では、ファイルまたはフォルダーのバージョンにラベルを適用します。 Visual SourceSafe では、明示的または暗黙的にファイルにラベルを付けることができます。 Visual SourceSafe で明示的にファイルにラベル付けした場合、そのファイルの新しいバージョンが作成されます。そのラベルを使用してファイルを取得すると、ラベルの作成時点で存在していたファイルのバージョンに対応する内容が取得されます。 明示的なラベルを移行する場合、コンバーターは Visual SourceSafe 内のラベル付けされたバージョンに対応するラベルを取得し、それを Team Foundation 内のバージョンに適用します。 ただし、これによって新しいバージョンが作成されるわけではありません。 Visual SourceSafe 内のフォルダーにラベルを適用すると、そのフォルダーの配下にあるすべてのファイルとフォルダーにラベルが暗黙的に適用され、コンバーターは新しいバージョンを作成しません。 暗黙的なラベルの場合、フォルダーの明示的なラベルを移行するときに Team Foundation 内の対応するバージョンが自動的にラベル付けされるため、コンバーターは何も行いません。 .gif "メモ") メモ
使用する Visual SourceSafe データベースに多数のファイルに適用される多数のラベルが含まれている場合は、移行プロセスが長引く可能性があります。このデータがチームに不要な場合は、ラベルを無視するように VSSConverter を設定できます。詳細については、このトピックで前述した「<Label migrate="false" />」を参照してください。
|
フォルダーのラベル付け |
Visual SourceSafe では、フォルダーにラベルを適用すると、そのフォルダーの配下にあるすべてのファイルとフォルダーが暗黙的にラベル付けされ、新しいバージョンは作成されません。 これらのフォルダーを移行する際、コンバーターは Team Foundation 内の対応するバージョンのフォルダーにラベルを適用します。 この動作は、ラベル付けされたフォルダー内部にあるファイルとフォルダーの現在のバージョンに自動的にラベルを適用します。 メモ
使用する Visual SourceSafe データベースに多数のファイルに適用される多数のラベルが含まれている場合は、移行プロセスが長引く可能性があります。このデータがチームに不要な場合は、ラベルを無視するように VSSConverter を設定できます。詳細については、「<Label migrate="false" />」を参照してください。
|
フォルダーの移動 |
フォルダー移動イベントでは、フォルダーの新規バージョンが Team Foundation に作成されます。 VSSConverter が移動対象フォルダーに含まれている項目の履歴全体を移行するのは、移動元フォルダーと移動先フォルダーの両方が同時に移行される場合だけです。 詳細については、「分析機能によって検出された懸案事項のレビューと解決」を参照してください。 メモ
フォルダーの移動イベントと復元イベントが組み合わされると、履歴データが正しく移行されない可能性があります。
|
復元 |
復元イベントの移行前に生じた履歴データは移行されません。 |
固定と固定の解除 |
Team Foundation バージョン管理では固定がサポートされていません。 VSSConverter は、2 つのラベルを作成することによって、固定されたファイルを移行します。 PINNED_LATEST ラベルは、固定されたファイルの固定されたバージョンおよび固定解除されたファイルの最新バージョンに適用されます。 PINNED ラベルは、固定されたファイルの固定されたバージョンに対してのみ適用されます。 移行後、PINNED_LATEST ラベルにより、Visual SourceSafe の Get Latest と同じファイルが取得されます。 ただし、ファイルを固定した後で、ファイルの名前変更やファイルの削除などチェックイン以外のイベントが発生した場合は、同じ PINNED_LATEST ラベルであっても異なるファイルが返されることがあります。 |
共有 |
Team Foundation バージョン管理は共有をサポートしていません。 Visual SourceSafe データベース内の共有ファイルは、共有時に存在していたファイルのバージョンをコピーし、コピーを移行先フォルダーに配置することによって Team Foundation バージョン管理に移行されます。 その後、各変更セットは共有ファイルの両方のコピーにレプリケートされます。 |
ファイルまたはフォルダーの削除取り消し |
ファイルまたはフォルダーの削除取り消しイベントを移行する際、コンバーターはそのイベントを再生して、ファイルとフォルダーの新しいバージョンを Team Foundation に作成します。 VSSConverter は、ファイル名またはフォルダー名、ファイルまたはフォルダーの削除が取り消されたときの日付と時刻、およびユーザー名を含む変更セットを作成します。 |
ソース管理バインド
VSSConverter は、各ソリューションのバージョン管理バインドを復元します。