Restoring a Configuration Management Project

The Restore Project action allows you to restore a configuration management project to a previously checkpointed revision. Restoring a project is useful when development must revert to an earlier version and no plans exist to proceed from the current version of the project. Any further development then proceeds from the restored project revision. The Restore Project action can be applied to both normal and variant projects.

The Restore Project action can potentially restore and checkpoint dropped subprojects that existed at the target revision, even if they are not currently a member of the project.

To restore a project through the GUI, select the configuration management project that you want to restore in either a Project or Sandbox view. Then, select Project > Restore. When a sandbox or subsandbox is selected, the corresponding master project is referenced.

Do not use the Restore Project action to create a new development branch from a previously checkpointed project. Create a new development path instead.

Integrity Lifecycle Manager restores a project as follows:

Therefore, for each configuration management project you restore, two revisions are generated. For example, if the head revision of the project is 1.4 and you decide to restore it to revision 1.2, the following project revisions are generated:

You would then continue your project development work from revision 1.6.

On the Selection tab, you can select the checkpoint to restore by selecting either a pre-defined revision or a specific revision.

If you want to restore a pre-defined revision, select Pre-Defined Revision and then one of the following:

• Head, which represents the latest checkpoint on the default branch of development. If no default branch is specified, it represents the latest checkpoint on the mainline.

If you want to restore a specific revision, select Specific Revision. The default revision is the most recent checkpoint. However, you can select a specific revision based on a checkpoint number on the Revisions tab. Or, you can select a specific revision based on a label on the Labels tab.

• You can effectively undo the Restore Project action by restoring the configuration management project to the pre-checkpointed revision.

• To restore a variant project to a specific project revision, the development path must exist in all subprojects referenced by the project revision.

• For a checkpoint that is performed on the current configuration management project revision, all subprojects are checkpointed. This includes subprojects that have not changed since the last checkpoint.

When restoring a project from a reference checkpoint, you can define the resulting configuration of subprojects in the project. All subproject configuration options result in the same subprojects and member contents being taken from reference checkpoint. Only the configuration of the subprojects is different. Any new subprojects that did not exist in the reference checkpoint are dropped, and any subprojects that no longer exist are added back.

The ability to specify the resulting subproject configuration is useful for scenarios where you want to control how the restore operation affects subprojects. You click Options to view and set Resulting subproject configuration. For example, assume that On development path except explicitly configured subprojects (Legacy) is selected. With this choice, only the current development path is affected. All subprojects that are not configured as build in the reference checkpoint are configured to the current development path. This means that member changes are performed on the subprojects on this development path when restoring the project.

For Resulting subproject configuration, you have the following choices:

• On development path except explicitly configured subprojects (Legacy) specifies that any subprojects that were configured the same as their immediate parent in the reference checkpoint are configured on the same development path as their immediate parent. If the immediate parent’s resulting configuration is on mainline, the subprojects are configured on mainline. All subprojects that are configured differently from their immediate parent are configured the same way that they were configured in the reference checkpoint.

• On development path specifies that all subprojects are configured on the same development path as the project to which you are restoring (or to mainline if the project is currently on mainline). Any subprojects that were configured as build in the reference checkpoint continue to be configured as build, pointing to the revision from the reference checkpoint.

• Lightweight (Build) specifies that all subprojects are configured as build subprojects, pointing to the revision from the reference checkpoint. Shared subprojects are configured as shared build subprojects. Note that “lightweight” is a legacy term for extendable development paths.

• Retain current configuration specifies that the current subproject configuration does not change, regardless of the configuration in the reference checkpoint. Any subprojects from the reference checkpoint that were dropped are added back and configured as build subprojects. Any subprojects that are currently configured as build retain their configuration. However, their revision is updated to point to the same revision from the reference checkpoint.