mklbtype

Creates or updates a label type object

Applicability

Product

Command type

ClearCase®

cleartool subcommand

Platform

UNIX®
Linux®

Windows®
Parent topic: Cleartool subcommands for base ClearCase and UCM
Parent topic: Commands for managing software development projects (base ClearCase and UCM)
Parent topic: Rational ClearCase command reference

Synopsis

mklbtype [ –rep/lace ] [ –glo/bal [ –acq/uire ] | –ord/inary ]
[ –pbr/anch ] [ –sha/red ]

[ –c/omment comment | –cfi/le comment-file-pname | –cq/uery

| –cqe/ach | –nc/omment ] label-type-selector ...

Description

The mklbtype command creates one or more label types with the specified names for future use within a VOB. After creating a label type in a VOB, you can attach labels of that type to versions of that VOB's elements, using mklabel.

Instance constraints

The same version label can be attached to multiple versions of the same element. (The versions must all be on different branches. If two versions were labeled JOHN_TMP on branch /main/bugfix, the version-extended path name foo.c@@/main/bugfix/JOHN_TMP would be ambiguous.) However, there are drawbacks to using the same version label several times in the same element:

  • It is potentially confusing.
  • In a version-extended path name, you must always include a full branch path name along with the version label (for example, foo.c@@\main\new_port\JOHN_TMP).

By default, a new label type is constrained to use on only one version in an element's entire version tree. This allows you to omit the branch path name portion of a version-extended path name (for example, foo.c@@/JOHN_TMP). The –pbranch option relaxes this constraint, allowing the label type to be used once per branch.

Recommended naming convention

A VOB cannot contain a branch type and a label type with the same name. To avoid problems, adopt this convention:

  • Use lowercase letters (a – z) for names of branch types.
  • Use uppercase letters (A – Z) for names of label types.

Restrictions

Identities

No special identity is required unless you specify the –replace option. For –replace, you must have one of the following identities:

  • Type owner
  • VOB owner
  • root (UNIX and Linux)
  • Member of the ClearCase administrators group (ClearCase on Windows)

Locks

An error occurs if one or more of these objects are locked: VOB, label type (with –replace only).

Mastership

(Replicated VOBs only) With –replace, your current replica must master the type.

Options and arguments

Handling of name collisions

Default
An error occurs if a label type named type-name already exists in the VOB.
–rep/lace
Replaces the existing definition of type-name with a new one. If you do not include options from the existing definition, their values will be replaced with the defaults (Exception: the type's global scope does not change; you must explicitly specify –global or –ordinary).

If you specify a comment when using –replace, the comment appears in the event record for the modification (displayed with lshistory –minor); it does not replace the object's creation comment (displayed with describe). To change an object's creation comment, use chevent.

Constraints:

  • You cannot replace either of the predefined label types LATEST and CHECKEDOUT.
  • If there are existing labels of this type or if the containing VOB is replicated, you cannot replace a less constrained definition (–pbranch specified) with a more constrained definition. (The default is once per element.)
  • When replacing a label type that was created with the –shared option, you must use –shared again; that is, you cannot convert a label type from shared to unshared.
  • When converting a global type to ordinary, you must specify the global type as the label-type-selector argument. You cannot specify a local copy of the global type.

Specifying the scope of the label type

Default
Creates an ordinary label type that can be used only in the current VOB.
–glo/bal [ –acq/uire ]
Creates a label type that can be used as a global resource by client VOBs in the administrative VOB hierarchy. With –acquire, mklbtype checks all eclipsing types in client VOBs and converts them to local copies of the new global type.

For more information, see the IBM Rational ClearCase Administrator's Guide.

–ord/inary
Creates a label type that can be used only in the current VOB.

Instance constraints

Default
A label of the new type can be attached to only one version of a given element.
–pbr/anch
Relaxes the default constraint, allowing the label type to be used once per branch in a given element's version tree. You cannot attach the same version label to multiple versions on the same branch.

Mastership of the label type

Default
Attempts to attach or remove labels of this type succeed only in the VOB replica that is the current master of the label type. The VOB replica in which the new label type is created becomes its initial master.
–sha/red
Allows you to create or delete labels of this type at any replica in the VOB family. If you also specify –pbranch, the replica must master the branch of the version you specify in the mklabel or rmlabel command. If you do not specify –pbranch, the replica must master the element of the version you specify in the mklabel or rmlabel command.

If a type is global and shared, additional mastership restrictions exist when you create instances of the type. You cannot create instances of the type unless the client VOB contains a local copy of the type, or the administrative VOB at the current site masters the type. For more information, see the IBM Rational ClearCase Administrator's Guide.

Event records and comments

Default
Creates one or more event records, with commenting controlled by your .clearcase_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.

Naming the label types

Default
The label type is created in the VOB that contains the current working directory unless you specify another VOB with the @vob-selector argument.
label-type-selector ...
Names of the label types to be created. Specify label-type-selector in the form [lbtype:]type-name[@vob-selector]

type-name

Name of the label type

See the cleartool reference page for rules about composing names.

vob-selector

VOB specifier

Specify vob-selector in the form [vob:]pname-in-vob

pname-in-vob

Path name of the VOB tag (whether or not the VOB is mounted) or of any file system object within the VOB (if the VOB is mounted)

See Recommended naming convention.

Examples

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.

  • Create a label type that can be used only once per element. Provide a comment on the command line.

    cmd-context  mklbtype –c "Version label for V2.7.1 sources" V2.7.1
    Created label type "V2.7.1".

  • Create a label type that can be used once per branch in any element's version tree.

    cmd-context  mklbtype –nc –pbranch REL3
    Created label type "REL3".

  • Change the constraint on an existing label type so that it can be used once per branch. (This change does not affect existing labels of this type.) 
    cmd-context  mklbtype –replace –pbranch –c "allow use on multiple branches" V2.7.1 
Replaced definition of label type "V2.7.1".
Feedback