si ci

CLI Reference > Configuration Management Commands > si ci

si ci

checks in members of a Sandbox

Synopsis

Description

si ci checks in and saves changes to Sandbox members. For example,

si ci --label="Pre-Release Candidate" --description="Ready for Review" c:/Documentation/Man_Pages/xml_man/si_add.1.xml

If you do not specify any members, si ci applies to all members of an associated Sandbox.

Check in is an operation that adds a new revision of a file to an archive. When a file is checked in to a revision other than the head revision or a branch tip revision, a new branch is created.

Assigning Revision Numbers

By default, when you check in a member, PTC RV&S automatically assigns a unique revision number to the new revision. It does this by incrementing the current revision number by one. For example, if the previous revision is 1.3, the new revision is assigned number 1.4.

You can choose the revision number of the changes you are checking in, so long as your revision number:

• is greater than the last revision number (you cannot use previously "skipped" revision numbers)

• has no leading zeros (zeros as complete revision numbers are acceptable)

• starts a new branch based on an existing revision

If you check in a revision using an already existing revision number, PTC RV&S attempts to add one to the revision number and check it in as that revision. If that revision already exists, PTC RV&S then chooses the next available branch number and creates a new branch.

For example, if you are checking in a new revision to an archive where the head revision is 1.7, the following numbers are valid:

• 1.8 (greater than head revision)--if you check in a revision as 1.7, which already exists, PTC RV&S assigns it 1.8

• 1.10 (greater than head revision)

• 1.72 (none of the numbers between 7 and 72 may be used afterwards)

• 2.0

• 1.7.1.1 (if it starts a new branch)

• 1.7.0.1 (leading zero as the branch number)

The following numbers are invalid:

• 1.3 even if there was no revision 1.3 previously

• 1.08 (leading 0 in last portion)

• 02.1 is considered the same as 2.1 (leading zero in branch number)

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.

• --[no|confirm]ignoreUnresolvedMerge

• controls whether to ignore a previously unresolved merge. For more information on merging revisions, see si merge and si mergebranch.

• -L label

• --label=label

• identifies a label that is applied to the new revision. Note the following about using labels:

• Labels cannot contain colons(:), square brackets ([ ]), or leading spaces.

• Labels cannot have the same format as a valid revision number.

• Labels that include spaces must be enclosed by quotes.

• PTC recommends not using hyphens (-) in labels. Using hyphens may cause some si commands to fail.

• --author=name

• specifies an author name.

• --[no]branch

• controls whether to force the creation of a branch revision.

If required, a branch revision is created even if this option is set to "no", for example, if you are checking in a member to a revision other than the head revision.

A branch is a revision path that diverges from the main line of development (also known as the trunk) in a member or project history. A branch is typically created by checking in a file to a revision other than the head revision. The most recent revision of a branch is called the tip revision.

PTC RV&S usually places new revisions at the top of the trunk, assigning them two-part revision numbers, such as 1.15. There are times, however, when you do not want your work to be checked into the trunk. You may be pursuing a line of development that will not be included in the finished product, for instance, or you may be doing post-release maintenance while development for the next release continues on the trunk.

Divergent lines of development in the same archive are managed through the use of branches. A branch is an independent revision line that uses an existing revision as its starting point. Members of a branch revision are identified by their revision numbers. Whereas revisions on the trunk are characterized by two-part revision numbers (for example, 1.2 or 3.5), branch revision numbers are prefixed with the number of the revision they start from. For example, if a branch revision is started from revision number 1.2, the members of that branch are numbered

1.2.1.1
1.2.1.2
1.2.1.3

and so on. The first two digits of the number identify the revision where the branch diverges from the trunk, and the last two represent a position on the branch.

• --[no|confirm]updateIfNotCurrent

• controls whether to update the member revision, even if the revision being checked in is not the member revision. This option only applies if --update is specified.

--noupdateIfNotCurrent means do not update the member revision.

--confirmupdateIfNotCurrent means ask before updating the member revision.

--updateIfNotCurrent always updates the member revision.

• --[no|confirm]checkinUnchanged

controls whether to force the checkin so that the new revision is checked in even if it is not different from the preceding one.

--nocheckinUnchanged means do not force the checkin.

--confirmcheckinUnchanged means ask before forcing the checkin.

--checkinUnchanged always forces the checkin.

• --[no|confirm]closeCP

• controls whether to close the associated change package.

--nocloseCP means do not close the change package.

--confirmcloseCP means ask before closing the change package.

--closeCP always closes the change package.

• --[no|confirm]convertArchiveOnGovernor

• controls whether to automatically convert a text store-by-delta archive to store-by-reference if the working file exceeds the maximum size. If you are using the database repository, your administrator may set the policy that determines the maximum size of text working files that can be stored in a store-by-delta archive. The policy is useful in preventing out of memory issues on the PTC RV&S Server when PTC RV&S attempts to difference large text files. If the file exceeds the maximum size during a check in, you can cancel the operation or convert the archive to store-by-reference.

--noconvertArchiveOnGovernor means do not convert a text store-by-delta archive to store-by-reference if the working file exceeds the maximum size. This cancels the check in operation.

--confirmconvertArchiveOnGovernor means ask before converting a text store-by-delta archive to store-by-reference if the working file exceeds the maximum size.

--convertArchiveOnGovernor always convert a text store-by-delta archive to store-by-reference if the working file exceeds the maximum size.

• -d desc

• --description=desc

specifies a description for the new revision. This option and the --descriptionFile option are mutually exclusive.

Descriptions that include spaces must be enclosed by quotes.

• --[no]defer

controls whether to delay the checkin operation in the project. The operation in the Sandbox still takes place immediately.

If reviews are mandatory, specify this option to submit the changes for review as a change package. If this option is not specified, a pending revision is created for the operation, that corresponds to a pending entry in the change package.

• --descriptionFile=file

specifies a file name, file, containing the description text for the new revision. This option and the -d or --description options are mutually exclusive.

• -l

• --[no]lock

controls whether PTC RV&S locks the new revision. Locking the new revision allows you to update the archive while retaining control of the revision. The type of lock used is the same as the lock type used when the file was checked out.

• --[no|confirm]moveLabel

controls whether the application should move a label from one revision to another.

◦ --nomoveLabel disables the moving of a label.

◦ --confirmmoveLabel displays a confirmation message.

◦ --moveLabel moves the label.

• --[no]retainWorkingFile

controls whether to keep the working file in the Sandbox after checkin. By default, a sparse Sandbox does not retain the working file after checkin.

• --[no|confirm]revertUnchanged

controls whether to revert an unchanged member, releasing the lock.

If specified, the --[no|confirm]checkinUnchanged option takes precedence over this option.

• --[no]saveTimestamp

controls whether to set the revision timestamp to the modification date and time of the working file rather than the current date and time.

• -u

• --unlock

unlocks the newly checked-in revision. This is equivalent to specifying --nolock.

• --[no]unexpand

controls whether to unexpand or ignore keywords in the member file prior to the check in. Keyword expansion is only available in text archives, not binary archives. For descriptions of the PTC RV&S keywords, see the PTC RV&S Help Center. Possible keywords are:

$Author: Warner, Carrie (cwarner) $
$CompanyInfo$
$Date: 2015/11/30 23:50:32IST $
$Header: si_ci.dita 1.2 2015/11/30 23:50:32IST Warner, Carrie (cwarner) Exp $
$Id: si_ci.dita 1.2 2015/11/30 23:50:32IST Warner, Carrie (cwarner) Exp $
$Locker: $
$Log: si_ci.dita $
Revision 1.2 2015/11/30 23:50:32IST Warner, Carrie (cwarner)
XML tagging fixes
Revision 1.1 2015/10/29 10:24:47EDT Flett, David (dflett)
Initial revision
Member added to project /rd/doc/Strategic/xmldocs/en/int-man_pages/si_ref/project.pj
$Revision: 1.2 $
$Name: 10-9_L10N_handoff1 10-9_L10N_handoff2 10-9_L10N_handoff3 10-9_L10N_handoff4 $
$ProjectLabel: $
$ProjectName: /rd/doc/Strategic/xmldocs/en/int-man_pages/si_ref/project.pj $
$ProjectSetting $
$ProjectRevision: Last Checkpoint: 1.1.1.96 $
$Revision: 1.2 $
$SandboxSetting $
$Setting $
$Source: si_ci.dita $
$State: Exp $

• --[no]update

controls whether to set the checked in revision as the project's member revision.

• --onNewerRevision=[confirm|cancel|resync|resyncByCp|]

controls what happens when the revision being checked in is not the member revision in the development path.

◦ --onNewerRevision=confirm means ask for confirmation of the action to be taken.

◦ --onNewerRevision=cancel means cancel the operation.

◦ --onNewerRevision=resyncmeans resynchronize the member revision into the working file and move the lock (if any) to the member revision. The check in operation is not completed. You should perform additional testing on the merged file before checking it in.

◦ --onNewerRevision=resyncbycp means resynchronize the member revision into the working file by change package, and move the lock (if any) to the member revision. The check in operation is not completed. You should perform additional testing on the merged file before checking it in.

If you specify a revision using the--revision option or force the creation of a branch using the --branch option, no action is required when checking in a member that is not the member revision.

• --[no|confirm]branchVariant

controls whether or not to create a branch when in a variant context and branching is optional. Branching is optional if the revision being checked in is the branch tip. If the revision is a previous revision on the branch, then a new revision branch must be created regardless of the value of this option. Note that this check is done once per member on the development path, and is not done again on future check in operations for that member. This option is useful for keeping changes in the variant separate from changes made in the mainline project.

• --[no|confirm]skipUpdateOnLockConflict

instructs PTC RV&S not to update the member revision if the member revision is exclusively locked by another user. This option is development path specific. If this option is not specified, the default is to confirm. This option is not available in the GUI, but can be set for the GUI from the si setprefs command

• --cancelOnInconsistentLineTerminators

specifies to cancel the operation if inconsistent line terminators are encountered.

• --normalizeInconsistentLineTerminators

if inconsistent line terminators are encountered, specifies to normalize the line terminators to native for the system. The working file is normalized and then the operation is deferred. Examine the file for correctness before submitting the deferred operation to be committed to the repository. If there are multiple operations that are impacted, each affected operation is deferred and other operations are committed if PTC RV&S is configured to do so.

• sandbox member...

identifies a specific member; use spaces to specify more than one member.

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.