uncheckout
Cancels a checkout of an
element
SYNOPSIS
- uncheck·out | unco [ –kee·p | –rm ] [ –cact ] pname ...
DESCRIPTION
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:
- A
dynamic view reverts to selecting a checked-in version of each element.
- A
snapshot view performs an update operation for each unchecked-out element.
(For snapshot views, there is an exception for the canceling of a directory
checkout. For more information, see “Canceling a Directory Checkout”).
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.
Canceling a Checkout in an Inaccessible View
You can cancel another dynamic view's
checkout by using a view-extended pathname to the element. For a snapshot
view or when a dynamic view is no longer accessible (for example, it was
deleted accidentally), a view-extended pathname does not work. Instead, do
the following:
- Enter
the command describe –long vob:pname-in-vob, where pname-in-vob is the VOB tag of the VOB
that contains the checked-out file. The output of this command includes a
list of views with checkouts in the VOB.
- Look
for the view-storage pathname of the inaccessible view, and note the view's
unique identifier (UUID).
- Use the UUID in the command rmview –uuid uuid to remove all of the view's checkout records from the VOB.
- Repeat
Step 3 for each VOB that may
have been accessed with the view.
You can also change reserved checkouts
in that view to unreserved. There is no way to cancel checkouts in an inaccessible
view.
Canceling a Directory Checkout
If you cancel a directory's checkout
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:
element-name.UUID
uncheckout displays
a message in such cases:
RESTRICTIONS
Identities
You must have
one of the following identities:
- Version
creator
- Element
owner
- VOB
owner
- root (UNIX)
- Member
of the ClearCase administrators group (ClearCase on Windows)
- Local
administrator of the ClearCase LT server host (ClearCase LT on
Windows)
Locks
An error occurs
if one or more of these objects are locked: VOB, element type, element, branch
type, branch.
Mastership
(Replicated
VOBs) No mastership restrictions.
OPTIONS AND ARGUMENTS
Handling of the File
- Default
- For file elements only, uncheckout prompts
you to specify whether to preserve a copy of the checked-out version of the
element:
A yes answer is
equivalent to specifying the –keep option; a no answer
is equivalent to specifying the –rm option.
- –kee·p
- Preserves the contents of the checked-out
version under a file-name of the form element-name.keep (or,
to prevent name collisions, element-name.keep.1, element-name.keep.2, and so on).
- –rm
- Does not preserve the contents of the
checked-out version. Thus, any edits that had been made to the checked-out
version are lost.
- –cact
- Cancels the checkout for each checked
out version in the current activity.
Specifying the Element
- Default
- None.
- pname ...
- One or more pathnames, each of which
specifies an element. The checkout in the current view is canceled, unless
you use a view-extended pathname to specify another view.
Note: Avoid using a version-extended
pathname. For example, you cannot use hello.c@@\main\sub1 to
cancel another view's checkout on the sub1 branch
of element hello.c.
EXAMPLES
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.
- Cancel
the checkout of file element util.c.
- (Dynamic
views) Cancel the checkout of file hello.h in the jackson_fix view,
and delete the view-private copy.
- Cancel
the checkout of directory subd after creating a new
element named conv.c.