Sharing Archives With Other Projects

Teams within organizations often reference the same files for several different products. This section describes two possible approaches to sharing resources using a simplified example in which two teams use a single header file.

• Team 1 works within configuration management project team1.pj and has one member, code.c.

• Team 2 has its own project, team2.pj, and has two members, program.c and header.h.

Team 2 was the first to use header.h and has the original file in its subdirectory. Team 1 needs to access header.h for code.c.

Some general administrative concerns with sharing resources are as follows:

Normally the team that first creates a resource owns it. However, when a resource is shared, its ownership comes into question. Who is authorized to make updates to header.h? Team 2 originally owned the file but team 1 may now need to make changes to it. Alternately, team 2 may want to retain ownership of header.h, restricting changes from team 1 members.

Once an archive is shared, the ACLs used to control permissions for that archive depend on how the shared archive is accessed. For example, if the archive is accessed through team1.pj, the ACLs for team1.pj control permissions, and, if the archive was accessed through team2.pj, the ACLs for team2.pj control permissions.

When team 2 checks in a new version of header.h, it normally only tests its correctness and compatibility with program.c. The changes may not be compatible with team 1’s code.c and could lead to a loss of functionality for code.c, if team 1 were to accept team 2’s changes. This could be solved by using different variants of the shared subproject for team 1 and team 2.

A related concern is the stability of the changes made to a shared resource. Teams 1 and 2 may have different release schedules and criteria. Even if team 2’s changes to header.h were technically compatible with team 1’s project, team 1 may still hesitate to accept any changes.

ACLs on shared subprojects are based on the canonical name of the subproject. For example, if project c:/test/project.pj accesses d:/common/library.pj as a shared subproject, the ACL would be based on the name for d:/common/library.pj.

The next section presents two possible solutions and briefly explores the related administrative concerns, along with ways you can use Windchill RV&S to help.