si projectci

CLI Reference > Configuration Management Commands > si projectci

si projectci

checks in members of a project through a project

Synopsis

Description

si projectci checks in and saves changes to project members through a project.

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.

• This command can be only used with the PTC RV&S API. It is supported in the CLI only for the purpose of prototyping PTC RV&S API implementaions. It is used to check in source information from third party applications to PTC RV&S configuration management projects. Use the si ci command to check in through a Sandbox

• You cannot check in symbolic link file members using this command. Symbolic link files require a Sandbox context.

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]differentNames

controls whether to allow different source file and member names.

• -L value

• --label=value

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=value 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]branchUpdate

controls whether to update the member revision, even if it is on a branch. This option stops the member revision from accidentally moving onto a branch if a branch was created during check out. This option only applies if --update is specified, --revision was not specified, and the member revision is on a different branch from the working revision.

--nobranchUpdate means do not update the member revision.

--confirmbranchUpdate means ask before updating the member revision.

--branchUpdate 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.

• -ddesc

• --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.

• --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 to keep locks on members.

• --[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]retainSourceFile

controls whether to keep the source file after checkin.

• --sourceFile=value

identifies the source file being checked in.

• --[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 checking it into the archive. Keyword expansion is only available in text archives, not binary archives. For descriptions of the PTC RV&S keywords, see the PTC PTC RV&S User Guide. Possible keywords are:

$Author: Warner, Carrie (cwarner) $
$CompanyInfo$
$Date: 2015/12/01 01:31:45IST $
$Header: si_projectci.dita 1.2 2015/12/01 01:31:45IST Warner, Carrie (cwarner) Exp $
$Id: si_projectci.dita 1.2 2015/12/01 01:31:45IST Warner, Carrie (cwarner) Exp $
$Locker: $
$Log: si_projectci.dita $
Revision 1.2 2015/12/01 01:31:45IST Warner, Carrie (cwarner)
XML tagging fixes
Revision 1.1 2015/10/29 10:24:57EDT 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 $
$RCSfile: si_projectci.dita $
$Revision: 1.2 $
$SandboxSetting $
$Setting $
$Source: si_projectci.dita $
$State: Exp $

• --[no]update

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

• --onExistingRevision=[resync|resyncbycp|confirm|cancel]

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

--onExistingRevision=resync means 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.

--onExistingRevision=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.

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

--onExistingRevision=cancel means cancel the operation.

• --[no|confirm]branchVariant

controls whether PTC RV&S creates a branch off the revision you are checking in, if you are working in variant Sandbox and this is the first time the member is checked in. This is useful for keeping changes in the variant separate from changes made in the mainline project.

• 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.