サーバー管理 > ワークフローと SCM プロジェクト > コンフィギュレーション管理サブプロジェクトの構成
  
コンフィギュレーション管理サブプロジェクトの構成
CLI EQUIVALENT 
si configuresubproject
サブプロジェクトを作成または追加した後で、必要に応じてタイプを変更できます。たとえば、通常のサブプロジェクトをビルド サブプロジェクトに変更して開発を中断したり、バリアント サブプロジェクトを通常のサブプロジェクトに変更してメイン トランク上の開発を続行したりできます。
たとえば、担当者が ABC Tools 開発チームに、amortization/project.pj の最新の安定したバージョンであるリビジョン 1.2 を使用してもらいたいと考えているとします。また、全体の開発チームにこのリリースでこれ以上の開発を進めてもらいたくないと考えています。そこで、amortization/project.pj サブプロジェクトをビルド サブプロジェクトとして構成します。
インタフェース
手順
GUI
「サブプロジェクトの構成」 を選択します。
Web
「プロジェクト」 > 「サブプロジェクトの構成」を選択します。
サブプロジェクトを構成する場合は、次のいずれかのタイプを指定できます。
「標準」。サブプロジェクトはメインラインの作業中のサブプロジェクトに構成されます。
「バリアント」 を選択した場合、サブプロジェクトは特定の開発パスに構成されます。
* 
「バリアント」 オプションは、使用可能な開発パスが存在しない場合は使用できません。
非アクティブ化されている開発パスは、「開発パス名」一覧には表示されません。
「ビルド」。静的サブプロジェクトは、開発をさらに進めるためでなく、プロジェクトをビルドまたはテストするために使用されるプロジェクトの特定のチェックポイントに構成されます。チェックポイントを指定するには、チェックポイント番号またはラベルを使用します。
構成間の変更
サブプロジェクトの構成時に行った変更は、プロジェクト全体とその中の共有サブプロジェクトに反映されます。このような変更を示すデルタが、「プロジェクト」ビューまたは 「サンドボックス」ビューに表示されます。たとえば、次のような差異が表示されます。
サンドボックス内の作業中のリビジョンが新しいメンバーリビジョンと異なる場合は、サブプロジェクトの元のバージョンに存在するメンバーと構成されたバージョンのメンバーの差異がデルタとして表示されます。
サブプロジェクトの元のバージョンに存在しないが構成されたサブプロジェクトに存在するメンバーがデルタとして表示され、新しいメンバーに対応するワーク ファイルがサンドボックス内にないことを示します。
サブプロジェクトの元のバージョンに存在するが、構成されたサブプロジェクト内に存在しないメンバーは、以前のメンバーとして表示されます。
サブプロジェクトの元のバージョン内にメンバーとして存在するが、構成されたサブプロジェクト内に存在しないサブプロジェクトは、以前のサブプロジェクトとして表示されます。
差異を解消するには、サブサンドボックスを再同期します。
共有サブプロジェクトの構成
共有サブプロジェクトを構成するときは、各共有サブプロジェクトが別々に構成されることに注意してください。これは、共有サブプロジェクトを構成するときに、再構成によってそのサブプロジェクトのすべてのインスタンスが変更されるわけではないことを意味します。たとえば、サブプロジェクト tools/project.pjAurora/project.pjLibra/project.pj という 2 つのプロジェクトから共有されている場合、Aurora/tools/project.pj の構成に対する変更は、Libra/tools/project.pj の構成には反映されません。
Source Windchill RV&SStandard サブプロジェクト
Source Windchill RV&SStandard (Windchill RV&S の以前のバージョン) で作成された構成されたサブプロジェクトまたはフリーズされたサブプロジェクトは、Windchill RV&S からアクセスすると、操作を中断させないで検出されます。このようなサブプロジェクトの形式は、再構成によって新しい形式に変更または更新するまで保持されます。