Cancels a checkout of an element
ClearCase (cleartool subcommand), Attache (command)
The uncheckout command cancels a checkout for one or more elements, deleting the checked-out version. Any metadata (for example, attributes) that you attached to a checked-out version is lost. After you cancel a checkout:
In Attache, if -rm is not specified, any corresponding local files are uploaded before the uncheckout command is executed remotely, so that they can be kept in the view if -keep is specified or if the keep query receives a yes answer. Local files that correspond to canceled checkouts are updated from the version selected by the view after the checkouts are canceled, and are made read-only.
The checkout version event record for each element is removed from its VOB's database. (There is no uncheckout event record.) Reserve and unreserve records are also removed.
If you checked out a file under an alternate name (checkout -out), you cannot use the alternate name to cancel the checkout-you must use the element name listed by ls -vob_only.
(ClearCase only) You can cancel another dynamic view's checkout by using a view-extended pathname to the element. But for a snapshot view, or in the case where a dynamic view is no longer accessible (for example, it was deleted accidentally), a view-extended pathname does not work. Instead, do the following:
You can also change reserved checkouts in that view to unreserved. There is no way to cancel checkouts in an inaccessible view.
If you cancel a directory's checkout in a dynamic view after changing its contents, the changes made with rmname, mv, and ln are lost. Any new elements that were created (with mkelem or mkdir) become orphaned; such elements are moved to the VOB's lost+found directory, stored under names of this form:
uncheckout displays a message in such cases:
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.5f6815a0a2ce11cca54708006906af65".
When you use uncheckout in a snapshot view, the changes made with rmname, mv, and ln are lost in the VOB because there is no lost+found directory, but the snapshot view does not reflect the VOB contents until you invoke update.
Permissions Checking: For each object processed, you must be one of the following: version creator, element owner, VOB owner, member of the ClearCase group. See the permissions reference page.
Locks: An error occurs if any of the following objects are locked: VOB, element type, element, branch type, branch.
HANDLING OF THE FILE. Default: For file elements only, uncheckout prompts you to decide whether to preserve a copy of the checked-out version of the element:
Save private copy of "util.c"? [yes]
A yes answer is equivalent to specifying the -keep option; a no answer is equivalent to specifying the -rm option.
SPECIFYING THE ELEMENT. Default: None.
Examples including 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 command interpreter prompt. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.
cmd-context uncheckout util.c
Save private copy of "util.c"? [yes] no
Checkout cancelled for "util.c".
cmd-context uncheckout -rm M:\jackson_fix\users_hw\src\hello.h
Checkout cancelled for "M:\jackson_fix\users_hw\src\hello.h".
cmd-context uncheckout subd
cleartool: Warning: Object "conv.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"conv.c.3d90000112fc11cba70e0800690605d8".
Checkout cancelled for "subd".
checkin, checkout, lscheckout, mkview, reserve, unreserve, update, attache_command_line_interface, attache_graphical_interface
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 1999 by Rational Software Corporation. All rights reserved. |