Creates a permanent new version of an element
Product | Command Type |
---|---|
ClearCase | cleartool subcommand |
ClearCase LT | cleartool subcommand |
Attache | command |
Platform |
---|
UNIX |
Windows |
To create a new version of an element, checkin makes changes in the VOB and in the view.
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:
Checked in "msg.c" version "/main/bugfix/26".
In Attache, any existing local files corresponding to pathname arguments are uploaded before performing the checkin remotely; directories are not uploaded.
A checkin event record is created, which can be listed with the lshistory command:
cmd-context lshistory msg.c
06-Aug.12:09 akp create version "msg.c@@\main\bugfix\26"
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 file or a linked Windows file in more than one location), checkin updates each instance of the file with the checked-in version.
Attache. By default, the new version of a file element is created by uploading the local file named pname to the view, copying the contents of the uploaded view-private file named pname (the checked-out version) to the VOB, deleting that file in the view, and then setting the local file to read-only. 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 and Attache 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. In Attache, the workspace copy is not updated.
In Attache, a warning is issued for each argument that has no corresponding local file, but the command will still execute remotely. For each successfully checked-in version, the local file is changed to be read-only.
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 ahead of you, you can check in your work by performing the following steps:
Merge from the current LATEST version on the branch to your checked-out version.
Enter the checkin command again.
(Dynamic views and Attache) 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 pathname. 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.)
See the mkelem reference page for information on creating a file element for a DO, and see Building Software for information regarding subsequent operations on DO versions.
Identities: You must have one of the following identities:
User who checked out the element
Element owner
VOB owner
root (UNIX)
Member of the ClearCase group (ClearCase on Windows)
Local administrator of the ClearCase LT server host (ClearCase LT on Windows)
Additional restrictions on UNIX:
If the element's set-UID bit is set, only the element's owner, the VOB owner, or root can check in the version.
If the element's set-GID bit is set, only a member of the element's group, the VOB owner, or root can check in the version.
Locks: An error occurs if one or more of these objects are locked: VOB, element type, branch type, element, branch, pool (file elements).
Mastership: (Replicated VOBs) Your current replica must master the branch on which you are checking in the version.
EVENT RECORDS AND COMMENTS. Default: Creates one or more event records, with commenting controlled by your home directory's .clearcase_profile file in ClearCase and ClearCase LT or your remote home directory's .clearcase_profile file in Attache (default: -cqe). See the comments reference page. Comments can be edited with chevent.
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 either of the following commands:
checkin -nc
checkin -cqe; at the prompt, press CTRL+D (UNIX) or CTRL+Z ENTER (Windows), or .RETURN
checkin; at the prompt, press CTRL+D (UNIX) 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.
SUPPRESSING WARNING MESSAGES Default: Warning messages are displayed.
CHECKING IN DERIVED OBJECTS. Default: checkin checks in both the data and configuration record for a derived object.
MANAGING SOURCE FILES. 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.
(or possibly, pname.keep.n). In Attache, this file is not downloaded to the workspace. -keep is the default when you use the -from option, because the current contents of the checked-out version would otherwise be lost.
|
|
MISCELLANEOUS OPTIONS. Default: checkin resets the new version's modification time to the check-in time. Also, checkin cancels the checkin operation for files managed by certain type managers, if the contents of the files match their predecessor versions.
SPECIFYING OBJECTS TO CHECK IN. Default: None.
activity-name | name of the activity |
The UNIX examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.
The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.
In cleartool single-command mode, cmd-context represents the UNIX shell or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.
After verifying its checkout comment, check in element util.c, using that comment.
cmd-context lscheckout -long util.c
10-May-99.16:11:07 Chuck Jackson (jackson.dvt@oxygen)
checkout version "util.c" from /main/4 (reserved)
by view: "oxygen/home/jackson/cj.vws"
"revise syntax"
cmd-context checkin -nc util.c
Checked in "util.c" version "\main\5".
Check in an element from an alternate file, discarding the checked-out version. Provide a comment on the command line.
cmd-context checkin -rm -from c:\users\cep\util.c -c "Release 1.1 update" util.c
Checked in "util.c" version "\main\6".
(ClearCase) Check in only the configuration record of a derived object, discarding its data.
cmd-context checkin -nc -cr hello
Checked in "hello" version "/main/1".
attache_command_line_interface, attache_graphical_interface, checkout, clearmake, config_spec, get, lshistory, merge, mkelem, mkeltype, mklabel, profile_ccase, put, rmver, uncheckout
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |