The lock command creates a lock on an entire VOB or on one or more file system objects, type objects, or VOB storage pools. A lock on an object disables operations that modify the object; a lock has no effect on read operations, such as lshistory. (Exception: see the section on cleartext pools in “Storage Pool Lock”.)
The VOB does not need to be mounted for you to lock type objects, storage pools, or the VOB itself. However, you need a view context (and therefore a mounted VOB if you're using a dynamic view) to lock elements or versions.
The following sections describe the several kinds of locks.
Locking an entire VOB disables all write operations to that VOB and forces a database checkpoint by causing a state flush. A typical application is locking a VOB to prevent it from being modified during backup.
You must lock a VOB before backing it up, and you cannot use the –nusers option. With –nusers, it is possible that the VOB will be modified during the backup, and locking with the –nuser option does not perform a database checkpoint.
Note: Locking a VOB does not lock its cleartext storage pools, because this would prevent read access to text_file, compressed_text_file, and binary_delta_file elements. (For example, it would prevent a locked VOB from being backed up.) To completely lock a VOB, you must also lock its cleartext pools, using one or more lock pool: commands. You may want to do this to move a cleartext pool.
In general, locking a type object disables these kinds of operations:
The following sections describe how these general rules apply to the different kinds of type objects.
You can create a subbranch at any version on a locked branch, using mkbranch. (Creating a subbranch does not modify the branch itself.)
In general, locking a trigger type does not inhibit triggers of that type from firing. Exception: Trigger firing is inhibited if a trigger type created with mktrtype –element –all, mktrtype –ucm –all or if mktrtype –type is made obsolete (using lock –obsolete).
Locking a VOB storage pool inhibits commands that create or remove the pool's data containers. It also prevents the pool's scrubbing parameters from being modified with mkpool –update. The following sections describe how this principle applies to the different kinds of storage pools.
Locking or unlocking a global type or one of its local copies locks or unlocks the global type and all local copies. For more information, see the Administrator's Guide.
An object becomes obsolete if it is processed with a lock –obsolete command. An obsolete type object or obsolete storage pool is not only locked, but is also invisible to certain forms of the lstype, lslock, lspool, and lsvtree commands. An obsolete VOB or obsolete VOB object is no different from one with an ordinary lock. You can change an object's status from obsolete to locked by using a lock –replace command:
Similarly, you can use a lock –replace command to make a locked object obsolete.
You can use this option to change a object's status from just locked to obsolete.
When locking type objects and storage pools, the command processes objects in the VOB containing the current working directory. To lock an entire VOB, you must specify a VOB.
Specify object-selector in one of the following forms:
vob-selector | vob:pname-in-vob | |
pname-in-vob can be the pathname 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). It cannot be the pathname of the VOB storage directory. | ||
attribute-type-selector | attype:type-name[@vob-selector] | |
branch-type-selector | brtype:type-name[@vob-selector] | |
element-type-selector | eltype:type-name[@vob-selector] | |
hyperlink-type-selector | hltype:type-name[@vob-selector] | |
label-type-selector | lbtype:type-name[@vob-selector] | |
trigger-type-selector | trtype:type-name[@vob-selector] | |
pool-selector | pool:pool-name[@vob-selector] | |
oid-obj-selector | oid:object-oid[@vob-selector] | |
The following object-selectors apply to the UCM usage model[a] | ||
activity-selector | activity:actvity-name[@vob-selector] | |
baseline-selector | baseline:baseline-name[@vob-selector] | |
component-selector | component:component-name[@vob-selector] | |
folder-selector | folder:folder-name[@vob-selector] | |
project-selector | project:project-name[@vob-selector] | |
stream-selector | stream:stream-name[@vob-selector] | |
In UCM object selectors, @vob-selector refers to a UCM project VOB |
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.
checkin, checkout, chevent, chpool, chtype, clearmake, comments, lshistory, lslock, lspool, lstype , lsvtree, mkattr, mkattype, mkbranch, mkbrtype, mkdir, mkelem, mkhlink, mkhltype, mklabel, mklbtype, mkpool, mktrigger, mktrtype, promote_server, rename, rmattr, rmbranch, rmdo, rmelem, rmhlink, rmlabel, rmtrigger, rmtype, uncheckout, unlock
Copyright© 2003 Rational Software. All Rights Reserved.