与其他项目共享存档
组织内的团队通常会对多个不同产品参考相同文件。本节通过两个团队使用单个页眉文件的简化示例，介绍了两种可能的资源共享方式。
在该场景中：
• 团队 1 在配置管理项目 team1.pj 中工作，并且有一个成员 code.c。
• 团队 2 有自己的项目 team2.pj，并且有两个成员，program.c 和 header.h。
团队 2 是第一个使用 header.h 的团队，并且其子目录中有原始文件。团队 1 需要访问 header.h 以获取 code.c。
Windchill RV&S 允许您使用 ACL 控制存档共享。
共享资源的一些常规管理问题如下所示：
文件所有权不明
文件通常归首先创建资源的团队所有。但是共享资源时，其所有权就会出现问题。谁有权对 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 的名称。
|
下一节将介绍两种可能的解决方案，并简要探讨相关管理问题，以及使用 Windchill RV&S 获得帮助的方法。
相关主题