si restoreproject

si restoreproject --project=c:/Aurora_Program/bin/Libra/project.pj --revision=1.34 --reason="Restore due to Exception Error"

When you apply the si restoreproject command, Windchill RV&S recursively checkpoints the selected project, then modifies it to reflect the member list of the target checkpoint. Any further development then proceeds from the restored checkpoint.

Restoring a project is useful when development must revert back to an earlier version and there are no plans to proceed from the current version of the project. Restoring a project is not an option when the goal is to test a particular version. The project is always checkpointed before and after the restore.

• You cannot restore a build project using the si restoreproject command.

• The si restoreproject command can potentially restore and checkpoint dropped subprojects that existed at the target revision, even if they are not currently a member of the project.

• Do not use the si restoreproject command to create a new development branch from a project checkpoint. For new development paths, you should instead create a new development path.

• To restore a variant project to a specific project revision, the development path must exist in all subprojects referenced by the project 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 (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 re-added.

The ability to specify the resulting subproject configuration is useful for scenarios where you want to control how subprojects are affected by the restore operation. For example, if you specify the --resultingSubprojectConfiguration=ondevpath option, only the current development path will be affected since all the subprojects (that are not configured as build in the reference checkpoint) will be configured to the current development path. This means that the member changes will be performed on the subprojects on this development path when restoring the project.

This command takes the universal options available to all si commands, as well as some general options. See the options reference page for descriptions.

If the reason text includes spaces, enclose the text in quotes.

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 (or mainline if their immediate parent’s resulting configuration is on the mainline). All other subprojects that are configured differently from their immediate parent are configured the same way that they were configured in the reference checkpoint.

ondevpath specifies that all subprojects are configured on the same development path as the project you are restoring to (or mainline if the project is currently on the 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.

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.

retainconfiguration 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 re-added 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.