Checkpointing a Configuration Management Project

Checkpointing a project creates a new revision of the project and adds it to the project history. When you checkpoint a project, you save all the information needed to recreate the project completely as it existed as of the checkpoint date. The saved information includes the project structure and the list of members with their revision numbers.

For example, Release 3.0 of the ABC Financial Toolkit is approaching and work on the amortization project has been completed and passed to Quality Assurance. To preserve the project structure, Steve checkpoints the amortization project.

When you checkpoint a project in Integrity Lifecycle Manager, it creates a revision of a project in the project history. You can view the history of a project, restore a project to an earlier checkpoint, and compare differences between checkpoints.

All checkpoints are transactional. This means that a checkpoint records the structure and contents of the project at the checkpoint date. It does not include anything added to the project or its subprojects after the checkpoint date, such as checkins or submitted change packages.

While the checkpoint is in progress, you can perform member and subproject operations on the project, but you cannot perform any operations that affect project checkpoints, development paths, or labels. You cannot perform the following operations:

• If the Checkpoint Unchanged Subprojects option is cleared when checkpointing a project, subprojects that have not changed are not checkpointed; instead the existing revision for the subproject is used in the parent project checkpoint revision.

When the Checkpoint Unchanged Subprojects option is cleared, the following is true:

◦ If the subproject revision was created prior to Integrity 10.7, the unchanged subproject is checkpointed and its revision incremented. Only subproject revisions created by Integrity 10.7 or later can be detected as unchanged.

• You can use the project’s revision number to keep track of your projects, but to simplify post-release maintenance, use a label to identify significant project development milestones when you checkpoint a project. A checkpoint label is a unique text string assigned by you to identify a new project checkpoint, for example, Beta. Labels cannot contain colons (:), square brackets ([ ]), or leading spaces. Additionally they cannot have the same format as a valid revision number.

If you specify a label that is the same as one used for another checkpoint in the history and have the MoveProjectLabel permission, the label from the earlier checkpoint is moved to the new checkpoint. For more information on permissions, contact your administrator.

• Using the Apply Label to All Members or Apply State to All Members options when checkpointing a project slows down the checkpoint operation considerably. Do not select these options unless there is a definite need to label or set the state of all members individually. Instead, consider using the Label Unchanged Subprojects option to add a project label (rather than a member label) to all subprojects in the configuration.

• The Label Unchanged Subprojects option adds the project label to both unchanged subprojects and build subprojects. To reduce the command impact on users, the labels are applied after the lock on the project hierarchy is released.

• The As Of option specifies the project configuration as of a specific date. For more information on date-based project configurations, see Working With Date-Based Project Configurations. Specifying a date in the past performs a retroactive checkpoint at that specific date.

Checkpointing as of a date can be useful to reduce the number of total checkpoints on a project by only retroactively checkpointing the exact project configuration that you intend to use as a baseline, instead of creating checkpoints of current project configurations that might never be used. When checkpointing as of a date, the best practice is to specify a label to facilitate later identification of that checkpoint.

Date-based checkpoints have all of the same capabilities as regular checkpoints, but they are identified differently when they are used or appear in the project history. A regular checkpoint is identified using an Integrity Lifecycle Manager revision ID; for example, checkpointing a project at 1.1 results in revision 1.2. However, a date-based checkpoint for a project whose nearest regular checkpoint (not date-based) prior to that date is at revision 1.1 results in revision of 1.1.0.0.date.identifier, where date is the date of the project configuration (presented in milliseconds since the epoch) and identifier is an integer (usually 0, but higher if there were simultaneous operations). For example, checkpointing a project configuration that was January 5, 2015, 19:51:29 GMT (and no simultaneous operations) results in a revision ID of 1.1.0.0.1420487490.0.

Note the following:

• If the format of date-based checkpoint revision IDs causes difficulty in visually determining the branch, use the graphical history view to determine the branch information.

• The As Of option is not supported in the Configuration Management Web interface.

Interface	Procedure
GUI	Select a project or Sandbox and select Project > Checkpoint
Web interface	Select a project and select Project > Checkpoint Project