公用项目
另一种方法是使用公用项目。您可以创建一个主项目，其中包含三个项目 (team1.pj、team2.pj 和 header.pj) 作为子项目。
在此结构中，共享资源的所有权是灵活的。两个团队都有公用项目的所有权，并有权利修改公用项目。
您也可以使用 ACL 权限将所有权和修改权授予一个团队，但不授予另一个团队。此解决方案提出了第二种备选方法，即创建单独的团队，负责公用项目中的所有更改。此方法还解决了以下情况中的兼容性问题：团队在公用项目中进行更改时，应了解是否有其他项目将该公用项目作为子项目。这样才能确保兼容性。
现在，团队 1 和 2 可以专注于更新自己的代码，都确信公用文件与其代码兼容。任何兼容性问题都可以联系负责处理此类问题的兼容性团队。
在此结构中进行开发时，用户可创建主项目的沙盒，并递归到相关子项目中。使用不同子项目中文件的想法可能会遭到反对。工作环境中的这种转变需要时间来调整，以适应新的操作程序。
从主项目递归会引发更新和发布标准的问题。但是，此解决方案还提供了一些针对该问题的控制措施。团队中的用户无需从主项目开始。相反，用户可以创建其团队项目的沙盒，然后创建公用项目的单独沙盒。这种分离允许灵活地决定所需的公用项目版本。
在这种情况下，公用项目有自己的发布周期，并每个周期中都有检查点。然后，每个团队可以根据公用资源的给定版本来选择创建公用项目的构建沙盒，并使用该沙盒进行开发。
或者，团队可能想要从给定发布基线继续在公用项目中开发，同时将他们的更改与其他团队的更改，以及其他团队的更改与公共项目隔离开来。然后，团队可以创建和使用公用项目的变型沙盒。
最后一种备选方法是从公用项目创建一个普通沙盒，并按原样使用该沙盒，接受它可能会不断变化。在开发的早期阶段，这种备选方法也许可以接受，甚至很有必要。这种类型的项目结构提供了这种灵活性，甚至允许在开发过程中更改决策。
公用项目的潜在问题
虽然公用项目提供了一种灵活的方法来管理开发过程，但在使用此方法时可能会出现两个问题：
公用项目的版本化不是特定于团队的
单个团队的项目不会自动参考该团队使用的公用项目版本，尤其是当您使用公用项目的构建或变型沙盒来确保稳定性并隔离其他团队的更改时。每个团队必须持续跟踪特定于其项目的公用项目的版本。
一种解决方案是为每个团队使用共享子项目的不同变型。
另一种解决方案是在团队维护的构建文件中记录公用项目的版本。然后，可以将这些构建文件添加到团队的项目中并随之存档，从而作为完整构建环境 (包括公用项目版本) 的永久记录进行存档。
构建规范的更改
此解决方案需要更改构建规范，因为工作文件位置已更改。
PTC RV&S 可以管理服务器信息库中任意位置的源文件。PTC RV&S 使用相对于项目文件的路径在同一目录或其子目录中标识项目成员。