親子関係の変更が必要な場合

ワークスペースの親を一時的または永久的に変更する必要があるのは、次のような場合です。

• 新しいプロジェクト階層 (新しい最上位レベルのワークスペース) を作成するため

  開発製品のリリース 1 が完成し、リリース 2 の開発準備を行わなければならない場合を考えてみましょう。この場合、次の作業が必要になります。

  • 「ファイル」⇒「ワークスペース作成」を使用して、リリース 2 用の新しい (空の) ワークスペースを作成する。

  • 「親子関係の変更方法」で説明した 2 つの方法のいずれかで、リリース 2 用のワークスペースをリリース 1 用のワークスペースの新しい親にする。

  • プットバックトランザクションを使用して、リリース 2 用のワークスペースにファイルをコピーする。

  • リリース 1 用のワークスペースの親を元の親に変更する。

• 新規リリースに機能を移動するため

  特定のリリース向けに開発している機能が予定のスケジュールで完成しなかった場合など、その機能の開発に使用されているワークスペースの親を次のリリースの統合ワークスペースに変更することができます。「親子関係の変更例」で、これと同様の理由から親子関係を変更する方法を示します。

• 複数のリリースに対してバグ修正を適用するため

  バグ修正作業が行われた場合、バグ修正を行なったワークスペースの親を階層間で次々に変更しながら、関連するすべてのワークスペースにバグ修正を適用する必要があります。親を変更するたびに、変更内容を新しい親に適用するため、ワークスペース管理ツールのプットバックトランザクションを実行します。「親子関係の変更例」で、これと同様の理由から親子関係を変更する方法を示します。

• ワークスペース階層を再構成するため

  • 階層に新しいレベルを追加する。

  • 階層からレベルを削除する (親子関係の変更操作時に新しい親を指定しない)。

  • プロジェクト階層内でワークスペースのブランチを再構成する。

• Codemgr_wsdata/parent ファイルが削除されて親を失ったワークスペースを正常な状態に戻すため

  何らかの理由でファイルが孤児になることがあります (たとえば、親が壊れた場合や、その Codemgr_wsdata/parent ファイルが削除された場合)。このような場合には、親子関係の変更機能を使用して、そのワークスペースの親子関係を修復できます。

親子関係の変更例

ソフトウェアの開発作業では、製品のあるバージョンでバグが修正され、修正済みコードを配布するためのパッチリリースが作成されることがよくあります。バグが修正されたコードは通常、製品の次回リリースにも組み込んでおかなければなりません。ワークスペース管理ツールを使用して製品の開発を行なっている場合には、親子関係の変更機能を使用して比較的容易にパッチを組み込むことができます。

次の例は、ある製品のリリース 1.0 のバグを修正するパッチが作成され、すでに開発が開始されているリリース 2.0 にこのパッチを組み込む場合を想定しています。

1. 作成ブリングオーバートランザクションを使用して、パッチが作成されたワークスペースのコピーを作成します (図 6-1)。これは、新しい親とのやりとりによって、そのワークスペースの内容が変更されるからです (ブリングオーバートランザクションにより、そのワークスペースと新しい親との間の同期がとられます)。

2. 前述の親子関係変更方法を使用して、該当ワークスペースのコピーの親を 1.0patch から 2.0 に変更します (図 6-1 を参照)。

   図 6-1 patch ワークスペースの親を新規リリースに変更

   
   

3. ワークスペースはこの後、新しい親から更新され、以後の作業には 2.0 からブリングオーバーしてきたコピーを使用します (図 6-2 の A を参照)。

4. パッチに対して行われた修正を、2.0 からブリングオーバーしてきたファイルを持つ patch 内でマージした後、2.0 ワークスペースにプットバックします。これで、これらの修正を子ワークスペース 2.0child から利用することができます (図 6-2 の B を参照)。

   図 6-2 ファイルのブリングオーバー、マージ、新リリースへの統合

   
   

5. ファイルを 2.0child にコピーした後、「編集」⇒「削除」⇒「ソースと Codemgr_wsdata ディレクトリ」を選択して patch を削除します (図 6-3 を参照)。

図 6-3 パッチファイルを 2.0child にコピーし、patch を削除