mklbtype
Creates or updates a label
type object
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 pathname 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 pathname, you must always include a full branch pathname
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 pathname portion of a version-extended pathname (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. For this reason, we strongly recommend that
you adopt this convention:
- Make
all letters in names of branch types lowercase (a – z).
- Make
all letters in names of label types uppercase (A – Z).
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)
- 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, 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 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 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]
See the section “Recommended
Naming Convention”.
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.
- Create
a label type that can be used only once per element. Provide a comment on
the command line.
- Create
a label type that can be used once per branch in any element's version tree.
- 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.)