si projectcpdiff
displays a list of the operations that occurred on a project between two checkpoints tracked in change packages.
Synopsis
si projectcpdiff [(-R|--[no|confirm]recurse)] [--fields=field1[:width1],field2[:width2]...] [--filter=value] [--format=value] [--height=value] [(-r rev)] [--width=value] [-x value] [-y value] [(-Pproject|--project=project)] [--projectRevision=rev] [(-S sandbox|--sandbox=sandbox)] [--devpath=path] [--[no]failOnAmbiguousProject] [(-?|--usage)] [(-F file|--selectionFile=file)] [(-N|--no)] [(-Y|--yes)] [--[no]batch] [--cwd=directory] [--forceConfirm=[yes|no]] [(-g|--gui)] [--hostname=server] [--password=password] [--[no]persist] [--port=number] [--quiet] [--settingsUI=[gui|default]] [--status=[none|gui|default]] [--user=name]
Description
si projectcpdiff displays a list of the operations that occurred on a project between two checkpoints (project revisions) or timestamps, if those operations were tracked in change packages. The displayed information can be used to inform decisions on changes that need to be propagated to a development path, to understand the work that was done on a project, or as part of analyzing a problem that occurred in a recent project revision (for example, you can identify how a member was modified that caused a problem).
The following is an example of using the command to return the entries between the checkpoints 1.2 and 1.5 for project and recursively for all the subprojects that it contains:
si projectcpdiff -P /specification/project.pj --projectRevision=1.2 -R -r 1.2 -r 1.5
The following are key considerations when using this command:
• This command only returns changes that were recorded in change packages. Operations that are not recorded in change packages, such as a restore project (or commands that used the bypass value for --changePackageId), are not represented in the command output.
• The project context (-P/--project and/or --projectRevision) is used to gain access to the project archive, but only the specified revisions (-r) are used by the command to determine the comparison.
• Modifications to member attributes are not included in the command output.
• If subprojects were added using a change package, only that operation is included in the command output. The members that were added with the subproject are not included in the command output because they were not recorded in the change package. Similarly, reconfigured subprojects appear in the command output, but modifications to the members of the subproject do not appear in the command output.
• The project comparison must be for the same line of development (the project mainline or a single development path). However, the originating revision that was branched to create the development path can also be specified the starting revision; for example, revision 1.2 can be compared with 1.2.1.1.
• The command output only displays the resulting member revision for each change package entry, not the original member revision.
• When propagations cause an update to a revision number, the intervening revisions are not included in the command output because the operation that created them is not in the change package for that time frame.
• The command accepts two revisions, one revision or no revisions. If only one revision is specified, then the supplied revision is the start revision and the end revision is the current project configuration on the development path (or mainline) to which the revision belongs. If no revisions are specified, then the start revision is the most recent checkpoint revision on the specified project configuration, and the end revision is the currently specified project configuration.
• The command ignores build subprojects since they are static and do not change over time. However, in cases where the configuration of a subproject changes over time, the subproject and its contents may be visible in the view. The command focuses only on the existing project structure at both the start and the end points specified for the command. Build subprojects or subprojects that did not exist at the start and end points are not visible in the view. Existing non-build subprojects at the start and end points are visible in the view. For example, an existing build subproject that is later converted to a variant subproject would appear in the view. A subproject created after the start period and later converted to a build subproject before the end date would not appear in the view.
Options
This command takes the universal options available to all
si commands, as well as some general options. See the
options reference page for descriptions.
• --fields=field1[:width1],field2[:width2]...
allows you to select fields to be printed, specified in the format field1[:width1],field2[:width2]....
Specifying the column [:width] (in pixels) for each field is optional. Fields are separated with a space.
The fields available for printing can be one or more of the following:
◦ bytesadded
displays the number of bytes added by the operation. For text files, this field displays 0.
◦ bytesdeleted
displays the number of bytes deleted by the operation. For text files, this field displays 0.
◦ configpath
displays the configuration path of the change package entry.
◦ id
displays the change package ID.
◦ istext
indicates if the change package entry has a text archive; true or false. If false, the entry is a binary archive.
◦ linesadded
displays the number of lines added by the operation. For binary files, this field displays 0.
◦ linesdeleted
displays the number of lines deleted by the operation. For binary files, this field displays 0.
◦ location
displays the archive location for members or the location of the parent project for subprojects (the canonical path).
◦ member
displays the name of the member or subproject affected by the operation.
◦ membertype
displays the type of project element affected by the operation (member or subproject).
◦ project
displays the name and path of the project where the operation was performed. If the operation occurred in a shared subproject, the subproject name and path are displayed. If the operation involved two different projects (for example, moving a member from one project to another), the command returns two entries, with the first entry the originating project and the second entry the destination project.
◦ revision
displays the member revision number.
◦ server
displays the server the change package resides on.
◦ summary
displays the change package summary.
◦ timestamp
displays the timestamp of the selected change package.
◦ type
displays how the member was added to the change package.
◦ user
displays the ID of the user who added the member to the change package.
◦ variant
displays the names of variant projects associated with the member.
• --filter=value
displays the change packages according to one of the following filters:
◦ user:name
displays change packages created by a specified username.
◦ type[:add|:addfromarchive|:drop|:import|:exclusivelock| :nonexclusivelock|:renamefrom|:renameto| :movememberfrom|:movememberto|:update| :updatearchive|:updaterevision| :createsubproject|:addsubproject| :addsharedsubproject|:configuresubprojectfrom| :configuresubprojectto|:movesubprojectfrom| :movesubprojectto|:dropsubproject]
displays change packages based on their entry type.
◦ member:<expression>
specifies a text string to filter change packages by member name.
• --format=value
defines an output format for user-formatted text. The default formatting is suitable for interpretation by most users; the various formatting options are provided for programmatic control.
This option and the --fields option are mutually exclusive.
--format options use the same values as --fields, but similar to a JAVA MessageFormat string (that is, it requires { } to surround each field). The --fields option automatically adds a newline on the end, but you must supply the newline for formats with a \n, for example:
si projectcpdiff --format="{project},{member},{revision}\n"
• -r rev
specifies one or more project checkpoints to compare. rev can be a valid checkpoint number or label. To compare two specified revisions of the project, use the -r option twice. If you only use the -r option once, the working project (or last checkpoint on a build project's branch) is compared to the specified project checkpoint. If you do not use this option at all, the working project (or build project checkpoint) is compared to the last checkpoint (or last checkpoint on the build project's branch).
The -r option when used with this command can also take the "asof:" identifier with a date, to return the project configuration as of a specific date. For example, -r asof:"April 28, 2014 3:33:45 AM GMT-05:00".
It is possible to specify the branch with the identifier, for example -r asof:"April 28, 2014 3:33:45 AM GMT-05:00"@1.3.1
It is possible to specify the development path with the identifier using the form asof:date:@:devpath, for example -r asof:"April 28, 2014 3:33:45 AM GMT-05:00"@:Release2
The following are additional forms may be displayed for configuration paths, and are represented here for information purposes:
asof:ts=timestamp.number asof:ts=timestamp.number@branch asof:ts=timestamp.number@:devpath
Diagnostics
See the
diagnostics reference page for possible exit status values.
Preferences
Using
si setprefs or
si viewprefs, you are able to set or view the preference keys for this command.
See Also