Cancels a checkout of an element



Command type


cleartool subcommand

VersionVault Remote Client

rcleartool subcommand






  • VersionVault:
    uncheck/out | unco [ –kee/p | –rm ] [ –nsrfm ] { –cact [ pname ... ] | pname ... }
  • VersionVault Remote Client:
    uncheck/out | unco [ –kee/p | –rm ] { –cact [ pname ... ] | pname ... }


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 uses the version-selection rules of the config spec to select a version.
  • A snapshot view copies from the VOB the version that was in your view when you performed the checkout operation. (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:

  1. 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.
  2. Look for the view-storage pathname of the inaccessible view, and note the view's unique identifier (UUID).
  3. Use the UUID in the command rmview –uuid uuid to remove all of the view's checkout records from the VOB.
  4. 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.

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:


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


ACL authorization

If ACLs are enabled, the principal must have one of the non-ACL authorization identities and the following permissions:

  • read-info on VOB object
  • read-info on the element
  • mod-checkout on the element

Non-ACL authorization

You must have one of the following identities:

  • Version creator
  • Element owner
  • VOB owner
  • root (UNIX® and Linux®)
  • Member of the VersionVault administrators group (VersionVault on Windows®)


An error occurs if one or more of these objects are locked: VOB, element type, element, branch type, branch.


(Replicated VOBs) No mastership restrictions.

Options and arguments

Handling of the file

For file elements only, uncheckout prompts you to specify 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.

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).
Does not preserve the contents of the checked-out version. Thus, any edits that had been made to the checked-out version are lost.
Cancels the checkout for each checked out version in the current activity.

MultiSite: cancelling an SRFM checkout

Cancels a checkout of a remotely mastered branch that was performed synchronously with a request for mastership (SRFM) of that branch. This option unsets the pending reserved state of the checkout that was set when the command checkout –srfm was issued.

Specifying the element

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.


The UNIX system and Linux 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 system and Linux shells 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.

    cmd-context  uncheckout util.c
    Save private copy of "util.c"? [yes] no
    Checkout cancelled for "util.c".

  • (Dynamic views) Cancel the checkout of file hello.h in the jackson_fix view, and delete the view-private copy.

    cmd-context  uncheckout –rm /view/jackson_fix/usr/hw/src/hello.h
    Checkout cancelled for "/view/jackson_fix/usr/hw/src/hello.h".

  • Cancel the checkout of directory subd after creating a new element named conv.c.

    cmd-context  uncheckout subd
    cleartool: Warning: Object "conv.c" no longer referenced.
    cleartool: Warning: Moving object to vob lost+found directory as
    Checkout cancelled for "subd".