checkin

For one or more elements, checkin creates a successor to a version that was previously checked out in the current view: the predecessor version. The version number of the successor is the next unused number on the branch. (If one or more versions have been deleted from the end of the branch with rmver, it may seem that some version numbers have been skipped.) An appropriate message is displayed:

A checkin event record is created, which can be listed with the lshistory command:

Only elements can be checked in. You cannot check in a view-private or local file; you must first make an element of the same name. Use the mkelem -ci command to simultaneously create an element and check in a view-private or local file as its first version.

checkin works differently in different contexts.

• Dynamic view. By default, the new version of a file element is created by copying the contents of the view-private file named pname (the checked-out version) to the VOB, and then deleting that file. The -keep and -from options alter this behavior.
• Snapshot view. By default, the new version of a file element is created by copying the contents of the file named pname (the checked-out version) to the VOB. The checked-in version remains in the view. (This version may not be the one specified by the config spec.) The -keep and -from options alter this behavior. If multiple instances of this file element are loaded into the view (because the load rules specify a hard-linked UNIX or Linux file or a linked Windows file in more than one location), checkin updates each instance of the file with the checked-in version.
• Web view. By default, the new version of a file element is created by copying the contents of the view-private file named pname (the checked-out version) to the VOB. The -keep and -from options alter this behavior.

After the element is checked in, your view typically selects the version you just created. However, in a dynamic view it is possible that your view selects another version (perhaps on another branch), because that version is specified by your config spec rules. In this case, checkin displays a warning message.

From the viewpoint of the VOB database, the new, checked-in version is the same object as the checked-out version. Thus, any metadata items (version labels, attributes, hyperlinks) that were attached to the checked-out version remain attached to the new version. And, for example, checkin followed by mklabel is equivalent to mklabel followed by checkin.

At the time you enter a checkin command, there may be several checkouts of the same version. At most one of the checkouts (perhaps yours) is reserved; all the others are unreserved. Your checkin command succeeds in either of these cases:

• Yours was a reserved checkout.
• All checkouts were unreserved, and no one has checked in a successor version.

If the command fails because someone else has a reserved checkout, you must wait until that checkout is resolved, with checkin, uncheckout, or unreserve. If the command fails because someone has checked in a successor version before you did, you can check in your work by performing the following steps:

1. Merge from the current LATEST version on the branch to your checked-out version.
2. Enter the checkin command again.

(Dynamic views) You can check in a derived object to make it a version of an element (a DO version). By default, both the data and configuration record of a derived object are checked in. To save disk storage, you can use the -cr option to check in only the configuration record, not the data. Checking in a nonshareable DO converts the DO, its sibling DOs, and its sub-DOs to shareable DOs.

clearmake can reuse or winkin a derived object only if it is stored under its original path name. Thus, a DO version created under an alternate name with checkin -from cannot be used by clearmake for build avoidance. (clearmake can still use the derived object named in the -from option, which is unaffected by this command.)

For information about creating a file element for a DO, see the mkelem reference page.

Default

Creates one or more event records, with commenting controlled by your home directory's .versionvault_profile file (default: -cqe). See the comments reference page. Comments can be edited with chevent.

-c/omment comment | -cfi/le comment-file-pname |-cq/uery | -cqe/ach | -nc/omment

Overrides the default with the option you specify. See the comments reference page.

Note: If a checkout comment exists (specified with the checkout command and/or generated to record changes to a checked-out directory), you can make it the checkin comment by using one of the following commands:

• checkin -nc
• checkin -cqe; at the prompt, press Ctrl+D (UNIX and Linux) or Ctrl+Z+Enter (Windows), or . Return
• checkin; at the prompt, press Ctrl+D (UNIX and Linux) or Ctrl+Z+Enter (Windows), or .Return

  Any other entry at the -cqe prompt specifies a new checkin comment, discarding the checkout comment (if any) for that element. The -c and -cq options always discard the checkout comment (if any) for each element processed.

Default

Warning messages are displayed.

-nwa/rn

Suppresses warning messages.

Default

checkin checks in both the data and configuration record for a derived object.

-cr (For derived object checkin)

Checks in only the configuration record for the specified derived objects. Each new DO version will have a configuration record, but no data. You can use many cleartool commands with such DO versions, such as catcr, diffcr, and mklabel (but not lsdo). DO versions are also visible when you use the ls command. However, a version created with this option cannot be opened or executed, because there is no data.

Default

• In a dynamic view, checkin deletes each view-private, checked-out pname file after using it to create a new version.
• In a snapshot view, checkin uses the checked-out pname file to create a new version, then loads the checked-in version into the view.

You can use the following options (which have no meaning for directory elements) to save view-private copies or to check in source files from other locations.

-kee/p

Saves the current contents of each checked-out version in a view-private file, in addition to creating a new version. The view-private file gets a name of the form pname.keep (or possibly, pname.keep.n). -keep is the default when you use the -from option, because the current contents of the checked-out version would otherwise be lost.

-rm

Removes each pname file after creating a new version. In a dynamic view, this is the default if you do not use the -from option.

-fro/m source-pname

Uses the contents of source-pname as the new version, instead of the view-private file pname. By default, -keep is invoked to preserve the contents of the view-private pname. The source-pname file itself is not affected. This option makes it easy to copy data from another location (outside the VOB, perhaps) into an element's version tree.

When using this option, specify only one pname argument.

Note:

• In a snapshot view, you cannot use a view-extended path name as source-pname.
• This option will not work on directories.

-pti/me

Preserves the modification time of the file being checked in. If you omit this option, cleartool sets the modification time of the new version to the checkin time. Use this option consistently for checkout and checkin operations: if you specify -ptime when checking out a file, then specify -ptime when you check it in.

Note: On some UNIX and Linux platforms, it is important that the modification time be preserved for archive files (libraries) created by ar(1) (and perhaps updated with ranlib(1)). The link editor, ld(1), complains if the modification time does not match a time recorded in the archive itself. Be sure to use this option, or (more reliably) store archive files as elements of a user-defined type, created with the mkeltype -ptime command. This causes -ptime to be invoked when the element is checked in.

-ide/ntical

Checks in the element even if the predecessor version is identical to the checked-out version. By default, the checkin operation is canceled in such cases.

Note: This behavior applies only to elements whose type manager computes version-to-version deltas (for example, elements of type text_file, binary_delta_file, and compressed_text_file). If an element's type manager does not compute deltas, checkin always creates a new version, even when it is identical to its predecessor. For example, a new version is always created for an element of type file, which uses the whole_copy type manager.

-ato/mic

Specifies that if the checkin operation should fail for one element, then it is to fail for all elements. By default, checkins are nonatomic.

• This option is valid only if the VOB administrator has used the protectvob command to enable atomic checkins for the VOB.
• The atomicity of a checkin operation is effective on a per-VOB basis. For example, if the specified elements reside in three VOBs, there will be three atomic transactions.
• A single checkin comment is applied to the entire set of new versions.
• This option is not valid for UCM.

Default

None.

-cact

Checks in each checked-out version in the change set of the current UCM activity in your view.

activity-selector ...

Checks in each checked-out version in the change set of each specified activity. Specify activity-selector in the form activity:activity-name[@vob-selector]

activity-name

Name of the activity

pname ...

The path names of one or more elements to be checked in.