This portion of the license file contains the functionality bits for the most commonly requested policy. ClearTrigger already has the functionality compiled in it for speed. Just turn it on.
Currently there are 24 bits evaluated.
The ABS recommended bits for a "day 1" ClearCase administrator are:111010000010001011111110
Select a bit number to view a more detailed description...
|To include functionality for...|
|0||Automatic removal of empty branches caused by uncheckout, rmbranch or rmver commands.|
|1||Automatically change ownership of all newly created elements to the current owner of the VOB. The default for the ClearTrigger region can be changed from the
|2||Prevent duplicate elements on hidden branches (classic Evil Twin avoidance).|
|3||Only allow 1 checkout of an element per branch.|
|4||Insure that all newly created Label type names are fully UPPERCASE and Branch type names are fully lowercase.|
|5||Only allow the current VOB owner to perform checkins on the main branch. The default for the ClearTrigger region can be changed from the
|6||User is queried for recursive checkins, checkouts and uncheckouts when directories are encountered.|
|7||Enforcement of an enterprise ClearCase Magic Path. User's MAGIC_PATH variable must exist and be set to the enterprise standard ensuring consistent element typing.|
|8||Prevent creation of new elements with embedded spaces in the name.|
|9||Checkins not allowed when the element is the destination of multiple merges.|
|10||Smart Checkins – unchanged files are automatically unchecked out when checkin is attempted.|
|11||Element Name Case Checking. Prevents "Foo.c" from being created when "foo.c" exists.|
|12||Atomic change bit – Elements can be grouped together such that they must be checked out, checked-in , or unchecked out together as a group.|
|13||Require that new element names have an extension. Inhibits the creation of foo and requires "foo.*".|
|14||Require that the user is notified when they checkout on a branch if the same element on that branch's parent branch has advanced and needs merging or rebasing.|
|15||Require that the user is notified when they checkin on a branch if the same element on that branch's parent branch has advanced and needs merging or rebasing.|
|16||Quickly prevent users (other than the VOB owner) from performing certain destructive commands from the list:
chmaster chtype (element type) rmbranch rmelem rmtype rmver).
|17||Automatically add execute permissions to new elements (programs and scripts) when those elements are created. When new file elements are added to the VOB that are known by name (i.e. *.pl, *.sh, .login, *.dll, *.exe, etc) or are typed to a known element type (i.e. scripts, perl_scripts, executables, etc) then owner, group and other execute permissions are added to the new file.|
|18||Prevent files named "core" from being added as new elements to the VOB.|
|19||Automatically protect newly created directory elements as 775 in the VOB. The default for the ClearTrigger region can be changed from 775 to any value by using the cleartrigger_alias ABS_bit_19_protection_override within the clearbits file.|
|20||Automatically remove ".contrib." files that are created when merges are performed. The files are removed after a checkin or uncheckout of the associated file element. The user can use the environmental variable ABS_CONTRIB_KEEP to ignore the value of the region defined functionality bit.|
|21||Automatically check for elements that might be moved to the VOB's lost+found when a directory version is unchecked out. Provide a warning for any found and give the user the option to continue with or cancel the directory uncheckout.|
|22||Automatically changes the ownership of newly created elements to match the ownership (user and group) of the element's parent directory.|
|23||This bit automatically will change the state of newly created checkouts to the 'unreserved' state.|
|Value||Defines this feature as...|
The Functionality Bits are listed just below the 'Special Users List' in the clearbits_file. The format for this section is a list of values (either 0 or 1) for the associated Functionality Bit. For example to enable Functionality Bits 1, 2 and 19 you would make an entry in the clearbits_file such as this: