他のプロジェクトとのアーカイブ共有

組織内のチームでは、同一ファイルを複数の製品のために参照することが少なくありません。ここでは、2 つのチームが 1 つのヘッダーファイルを使用する 2 通りのリソース共有方法を、簡単な例を使用して説明します。

• チーム 1 は、コンフィギュレーション管理プロジェクト team1.pj 内で作業しています。このプロジェクトには 1 つのメンバー (code.c) があります。

• チーム 2 には独自のプロジェクト team2.pj があり、このプロジェクトには 2 つのメンバー (program.c と header.h) があります。

チーム 2 が最初に header.h を使用したため、元のファイルはこのチームのサブディレクトリにあります。チーム 1 は、code.c で header.h にアクセスする必要があります。

通常、リソースを最初に作成したチームが所有者になります。ただし、リソースが共有されると、その所有者が不明確になります。header.h を更新する権限は誰にあるのでしょうか。最初はチーム 2 がファイルを所有していましたが、チーム 1 でこのファイルを変更する必要が生じる場合もあります。一方、チーム 2 が引き続き header.h を所有し、チーム 1 による変更を制限する場合も考えられます。

アーカイブの共有後は、共有アーカイブへのアクセス方法によって、アーカイブに対する権限を制御する ACL が決まります。たとえば、アーカイブに team1.pj 経由でアクセスした場合は team1.pj の ACL によって、team2.pj 経由でアクセスした場合は team2.pj の ACL によって、それぞれ権限が制御されます。

チーム 2 が header.h の新しいバージョンをチェックインするとき、通常は program.c での正当性と互換性だけがテストされます。この変更はチーム 1 の code.c と互換性がない場合もあり、チーム 1 がチーム 2 の変更を受け入れると code.c が機能しなくなる可能性があります。これを解決するには、チーム 1 とチーム 2 とで異なるバリアントの共有サブプロジェクトを使用します。

これに関連して、共有リソースに加えられた変更の安定性の問題もあります。チーム 1 とチーム2 では、リリースのスケジュールや条件が異なる可能性があります。チーム 2 による header.h の変更とチーム 1 のプロジェクトとの間に、技術的には互換性があったとしても、チーム 1 がすべての変更を喜んで受け入れるとは限りません。

共有サブプロジェクトの ACL は、サブプロジェクトの正規名に基づきます。たとえば、プロジェクト c:/test/project.pj が d:/common/library.pj に共有サブプロジェクトとしてアクセスした場合、ACL は d:/common/library.pj の名前に基づきます。

次の項では、2 通りの解決方法を示し、関連する管理上の問題とその対処に役立つ Windchill RV&S の使用方法を簡単に説明します。