Delete Session Phases
Before describing the commands and their subcommands in more detail, the following diagram provides an overview of the delete session phases:
Delete session phases
 |
At any time during the delete session, you can run the --status subcommand to determine the status of the delete session.
|
1. The Mark phase specifies projects or archives that are new candidates for deletion. It (and consequently the delete session) begins by using the --mark subcommand to specify objects to be deleted. If projects are specified, the --mark subcommand determines what objects are to be deletion targets (projects or archives to be deleted) and what objects are to be kept candidates.
|
|
The PTC RV&S server only supports one delete session at a time and additional targets cannot be added with a second invocation of the --mark subcommand.
|
Kept candidates are subprojects or members that are not deleted for one of the following reasons:
◦ Subprojects or members are not located in the directory tree of any of the projects specified.
◦ You do not have DeleteProject permission for the specified project or its development paths.
◦ You do not have DeleteArchive permission for the specified or affected member archives.
◦ You used the --nodeleteIfInUse option, and the projects are referenced by an outside link. The link can be that the projects are shared subprojects in projects not specified for the delete session. Links also include every past or present subproject and member archive of every branch of the project specified (mainline, variant, or dropped variant).
◦ You used the --nodeleteIfInUse option, and the members are referenced by an outside link. The link can be to any revision referenced in another project.
|
|
If you restore deleted projects at a later date, the kept candidates do not maintain their linkages with restored projects.
|
The Mark phase is complete when all candidates are converted to kept candidates or delete targets. At this time, you can use the --status subcommand to view information on delete targets and kept candidates.
|
|
All delete targets are marked by the server such that they cannot be changed, and links to them cannot be added by user operations. Existing links can be duplicated (such as creating a development path) as this does not change the results of --mark. Kept candidates are not restricted.
Once marked, projects (and their members) cannot be modified using commands other than si deleteproject. For example, you cannot check in a member of a marked project. Once marked, if the projects or members need to be modified before they are deleted, a rollback must first be performed.
|
2. The Dump phase creates backups of the marked projects in the database using the --dump subcommand. If projects are marked, the command recursively creates backups of the projects and archives to a backup table in the database (dumping them). However, the subcommand does not backup all of the members, subprojects, and variants that are referenced by those projects, only the in-tree objects.
|
|
At any phase before Commit, you can run the --rollback subcommand to discard the target information, and end the delete session with the database unchanged. Once the subcommand completes, you can begin a new delete session with the --mark subcommand.
|
 |
The Dump phase is not available for the si deletearchive command. Using this command deletes archives without creating backups for them. Archive backup (and restore) is not available for individual archives; only projects that include archives. If you require archive backups, use the si deleteproject command instead.
|
Alternatively, projects can be copied to the backup schema without using si deleteproject --dump, by using si migrate --dumpToBackup projectList, where projectList is a selection of projects. .
3. The Commit phase deletes all of the delete targets identified in the Mark phase, breaks links to deleted objects, and ends the delete session. Begin the commit phase using the --commit subcommand.