project_grouping command

Use project groupings to organize projects by release and purpose for the update operation. The task and baseline properties for a project grouping are used at project update so that member selection is consistent across all projects. A project can be a member of only one project grouping. A project grouping is created automatically when you create a project.

Project groupings can be private or non-private. All projects in a private project grouping have the same owner, release, purpose, and state as the project grouping. Private project groupings are identified in one of these ways:

  • My release purpose Projects

    The current user owns the project grouping and the database is not DCM-enabled, or the project grouping was created in the local database. The following is an example of a private project grouping,My CM/6.5 Insulated Development Projects.

  • owner's release purpose Projects

    A different user owns the project grouping and the database is not DCM-enabled, or the project grouping was created in the local database. The following is an example of a private project grouping, John's CM/6.5 Insulated Development Projects.

  • My release purpose Projects from Database dbid

    The current user owns the project grouping, the database is DCM-enabled, and the project grouping was not created in the local database. The following is an example of a private project grouping, My CM/6.5 Insulated Development Projects from Database D.

  • owner's release purpose Projects from Database dbid

    A different user owns the project grouping, the database is DCM-enabled, and the project grouping was not created in the local database. The following is an example of a private project grouping,John's CM/6.5 Insulated Development Projects from Database D.

All projects in a non-private project grouping have the same release, purpose, and state as the project grouping. Non-private project groupings are identified in one of these ways:

  • All release purpose Projects from Database dbid

    For DCM-enabled databases, the dbid is the ID of the database where the project grouping was created. The following is an example of a non-private project grouping, All CM/6.5 Integration Testing Projects from Database D.

  • All release purpose Projects

    For databases not DCM-enabled, such as All CM/6.5 System Testing Projects.

Every local project grouping is associated with the process rule that corresponds to its release and purpose. A project grouping can have only one related process rule.

However, note that in some cases, all projects in a project grouping might not have update properties specified by the project grouping. Projects that use process rules have the same update properties. A project grouping can contain projects that do not use process rules, or even projects that update using objects instead of tasks. The ability to place them in the same grouping creates baselines from the full set of projects.

To have the appropriate update properties, project groupings have many associations with other objects in the database. Because process rules use folders and tasks, these same folders and tasks are associated with a project grouping that use process rules. Additionally, a project grouping has a set of saved tasks, a set of additional tasks, a set of removed tasks, and a set of automatic tasks. Each set of tasks is specific to the project grouping. You can also add and remove tasks in the grouping. Every local project grouping also has a relationship to a baseline, if the process rules use baselines.

The project_grouping command supports these subcommands.

Feedback