Eric J. Ostrander's
ClearCase / ClearQuest pages.


ClearCase, how do I ...


Attributes   |   Branches   |   CCLT   |   CQ integration   |   DDTS integration   |   Derived Objects   |   Elements   |   Hyperlinks   |   Interop UNIX/NT   |   Labels   |   MetaData   |   Misc.   |   MultiSite   |   RCCO   |   Regions / licenses / registry   |   Reports   |   Triggers   |   Views   |   VOBs   |   UCM   |   Web


Simple, case-insensitive search:

IMPORTANT: Confer with official Rational Software documentation before executing any of the examples.



 

Attributes
Back to the TOP
Create an attribute type.   (mkattype)
Modify an attribute type.
Remove an attribute type.   (rmtype)
Attach an attribute.   (mkattr)
Remove an attribute from an element.   (rmattr)
Modify an object's attribute value.
Rename an attribute type.   (rename)
Find objects with a certain attribute/value.   (find)
Change an attribute type's constraints.

 

Branches
Back to the TOP
Create a branch.   (mkbranch)
Remove a branch.   (rmbranch)
Merge branches.   (merge,findmerge,clearmrgman,xmldiffmrg)
Create a branch type.   (mkbrtype)
Remove a branch type.   (rmtype)
Modify an existing branch type.   (mkbrtype)
Rename a branch or branch type.   (chtype,rename)
Set up a private branch.   (Windows only)
Finish a private branch.   (Windows only)

 

CCLT
Back to the TOP
Differences between CC and CCLT
Upgrade CCLT to CC

 

Derived Objects
Back to the TOP
Derived objects.
List derived objects.   (lsdo)
Remove a derived object.   (rmdo)
Configuration records.
Winkin a derived object.   (winkin)
Use clearaudit.
View a configuration record.   (catcr)
Diff configuration records.   (diffcr)
Create non-shareable derived objects.
Build in CC.   (clearmake)




ClearQuest integration
Back to the TOP
CC/CQ non-UCM integration.
Remove the CC/CQ non-UCM integration.
Reset the CC/CQ integration CQ login.
Set CC/CQ non-UCM integration policy.




DDTS integration
Back to the TOP
CC/DDTS integration: NT
CC/DDTS integration: UNIX
Suppress requests for DDTS bug numbers.
Force the entry of a real DDTS bug number.
Remove the CC/DDTS integration.

 

Elements
Back to the TOP
Checkout an element.   (co)
Checkin an element(s).   (ci)
Uncheckout an element.   (unco)
Uncheckout an element that belongs to a missing view.
Refer to an element.
Create an element.   (mkelem)
Remove an element.   (rmelem)
Change an element's permissions.   (protect)
Rename an element.   (mv)
Link to another element.   (ln)
Remove a reference to an element or symbolic link.   (rmname)
Remove references to view related elements from a VOB.
Merge elements.   (findmerge,merge,clearmrgman,xmldiffmrg)
Create an element type.   (mkeltype)
Change an element's type.   (chtype)
Set a default element type.
Move an element between VOBs.   (relocate)
Describe an element.
Diff two text elements.   (diff,cleardiff,xcleardiff)
Remove a merge arrow from an element's version tree.   (rmmerge)
Remove a version of an element.   (rmver)
Create a directory element.   (mkdir)
List details about the contents of an element version.   (annotate)
List/find CHECKEDOUT elements.   (lsco,lscheckout,lsprivate,ls,clearfindco)
Remove a trigger from an element.   (rmtrigger)
Find all elements with a certain characteristic.   (find)
Modify element attributes en masse.
Determine the storage location of an element.   (mvfsstorage, dump)
Label an element.   (mklabel)
Recursively checkin/uncheckout all checkouts.
Recursively checkout all elements in a tree.
Determine what pools are assigned to an element. (describe)
Assign different storage pools to an element.   (chpool)
Change the checkout status to unreserved/reserve.   (unreserve,reserve)
List the history of an element.   (lshistory)
Count the number of elements in a VOB.
Checkin all elements from all views.
Find ALL elements in a VOB.   (find)
Create a symbolic link. (ln)
Retrieve element versions not loaded in a snapshot view. (get)
Restore a single element from backup.
Recover a previous version of an element. (merge)
Recover a removed element.
Find symbolic links. (find)
Find the LATEST versions. (find)
Remove elements from the lost+found directory.
Unreserve a snapshot checkout even if the loaded files are offline.
Find all elements that have a particular branch.
Determine an element's name given its data container.
Preserve the modification time during mkelem or checkin.
Import large numbers of elements.   (clearexport_*,clearimport,clearfsimport)
Force the merge tool to appear even if a merge isn't necessary. (merge)
Find all elements modified since a certain date-time.
Increase the maximum size allowed for an element.

 

Hyperlinks
Back to the TOP
Create a hyperlink type.   (mkhltype)
Remove a hyperlink type.   (rmtype)
Rename a hyperlink type.   (rename)
Attach a hyperlink.   (mkhlink)
Remove a hyperlink.   (rmhlink)
Use predefined hyperlinks: AdminVOB, Merge, etc...
Determine a hyperlink ID.
View hyperlinks.
Stop hyperlink inheritance.

 

Interop UNIX/NT
Back to the TOP
Connect Windows to Unix. (general)
Coordinate Unix/Windows user and group names.
Coordinate Unix/Windows regions.
Use CCMS as an interop solution.
Convert end-of-line characters.   (msdostext_mode)
Install hclnfsd/pcnfsd.
ClearCase File Server (CCFS)
MicroSoft Service for Unix (MS-SFU or WSFU)
File access between operating systems.
Set VOB interop mode.
Access a Windows VOB from a Unix client.

 

Labels
Back to the TOP
Create a label type.   (mklbtype)
Remove a label type.   (rmtype)
Rename a label type.   (rename)
Attach a label.   (mklabel,clearapplywizard)
Remove a label.   (rmlabel)
Find instances of a label.   (find)

 

MetaData
Back to the TOP
Types & supertypes.
Create a type.   (mk??type)
Remove a type.   (rmtype)
Set a default element type.
Rename a type.   (rename)
Global types.   (Administrative VOBs)
Copy a type.   (cptype)
Lock and/or obsolete a type.   (lock,unlock)
List all MetaData types in a VOB.

 

Misc.
Back to the TOP
cleartool command
CC tutorial.
clearcase_albd   (general)
Lock and unlock objects.   (lock,unlock,lslock)
Change event record comments.   (chevent)
View CC logs.   (getlog,cleargetlog)
Collect info for Rational support.   (clearbug,clearbugnt)
Get information about CC objects.
Get information about the current host.   (hostinfo)
Get information about CC commands/man pages.   (apropos,man)
Determine the CC version and patches installed.   (cleartool)
Create command aliases.
.clearcase_profile   (general)
Customize a Windows context (right-click) menu.   (clearmenuadmin)
Performance tuning.
Use the UNIX CC GUI.   (xclearcase)
CC group permissions.
Schedule jobs.   (at, winat, crontab, schedule, disprun)
Stop and start CC services.
Enable checksums on SunOS 4.1.x, HP-UX 9.0.x and UnixWare 2.1.x.
cleardlg
Count the number of elements in a VOB.
Patch CC.
Get help. (man hyperhelp apropos)
Build in CC.   (clearmake)
Customize ClearCase Explorer tools.
Prompt users with/for information. (clearprompt)
Find objects created by a certain user.
Find objects created since a certain date.
Disconnect CC from the network.
Determine what ports CC uses.
Web Authoring Integration Wizard.
Determine where CC is installed. (ATRIAHOME)
Determine the location of the MVFS drive.
Remotely/automatically reset a Windows albd service password. (albd_pw_util.exe)
Get the status of a remote albd service.
Change the "clearcase" group on Windows.
ClearCase Automation Library (CAL)
ClearCase File System (CCFS)
Add/remove a view shortcut page to/from the CC Explorer.
Merge non-CC files. (merge)
Create separate "site defaults" files for installation.
Perform a silent un/install.
Change permissions on all objects in a VOB.
Uninstall CC even if MVFS isn't working on Unix.
Recompile MVFS on Red Hat Linux.

 

RCCO (Rational ClearCase Online)
Back to the TOP
General.
Download elements without checkout.

 

Regions, licenses & registry
Back to the TOP
Create a region.   (mkregion)
Remove a region.   (rmregion)
Rename a region.
List regions.   (lsregion)
Licenses.   (clearlicense)
Check the consistency of a registry.   (rgy_check)
Switch to the backup registry server.   (rgy_switchover)
List the clients of a registry/license server.   (lsclients)
List the registry/license servers of a client.   (hostinfo)
Move a client to a new region.
Determine a computer's current region. (hostinfo)
Designate a backup registry server. (rgy_backup)
Set the registry password. (rgy_passwd)
Set up a backup license server.

 

Reports (Windows only)
Back to the TOP
Generate a CC report.
Create a custom CC report.
Create a CC report using SoDA for Word.
Extend SoDA source domains.

 

Triggers
Back to the TOP
Set up a trigger.   (mktrtype)
Remove a trigger from an element.   (rmtrigger)
Remove a trigger type.   (rmtype)
Find all elements with a certain trigger attached.   (find)
Find all triggers attached to an element.
Attach a trigger to a specific element.   (mktrigger)
Prompt users with/for information. (clearprompt)
Ensure duplicate element names are not used (evil twin).
Replicate triggers in a MultiSite environment.

 

Views
Back to the TOP
Create a dynamic view.   (mkview)
Set to a dynamic view.   (setview)
Remove a view.   (rmview)
List views or a view's properties.   (lsview)
Snapshot views. (create,remove,update,hijacked)
Modify a view's rules.   (edcs,setcs)
Rename a view.   (rmtag,mktag)
View profiles.
Reformat a view. (reformatview)
List view-private files.   (lsprivate)
Start and stop a view.   (startview,endview,stopview)
Recover "stranded" view-private files from an unavailable VOB.   (recoverview)
Remove derived objects from view storage.   (view_scrubber)
Remove references to view related elements from a VOB.   (rmview)
Modify a view's properties/permissions.   (setcache,chview)
Set and list sitewide view properties.   (setsite,lssite)
Create a web snapshot view.
Determine diskspace used by a VOB or view.   (space)
Determine the currently set view.   (pwv)
Determine view and VOB server processes.   (albd_list)
Designate registered view and VOB storage locations. (mkstgloc)
List registered view and VOB storage locations. (lsstgloc)
Remove view and VOB storage location registrations. (rmstgloc)
Add an existing view or VOB to a new region. (mktag)
Dynamic view .specdev file.
Retrieve element versions not loaded in a snapshot view. (get)
Determine the location of snapshot view loaded files.
Automatically have views restart after reboot. (Windows only)
Determine when a view was last accessed. (lsview)
Set what shell is used when setting to a view.
Load snapshot view files to multiple locations.
Access elements from non-CC hosts.
Remove a snapshot view whose view root is missing.
Emulate a UCM view with a base CC view.
Remove a view shortcut from the ClearCase Explorer. (Windows only)
Determine if a view is dynamic or snapshot given its viewtag.

 

VOBs
Back to the TOP
Create a VOB.   (mkvob,clearvobtool)
Remove a VOB.   (rmvob)
Rename a VOB.   (register,rmtag,mktag)
List available VOBs.   (lsvob,clearvobadmin)
List VOB history.   (lshistory)
Get a listing of a VOB's properties. (describe)
Mount or unmount a VOB.   (mount,umount)
Move a VOB. (vob_siddump,vob_sidwalk)
Modify a VOB's permissions/properties.   (protectvob,mktag)
Register a VOB in a new region.   (register,mktag)
Check a VOB's consistency.   (checkvob,dbcheck)
Make a copy of a VOB.
Designate an administrative VOB.
List VOB replicas.   (lsreplica)
Reformat a VOB.   (reformatvob)
Determine diskspace used by a VOB or view.   (space)
Backup a VOB.
Restore a VOB from backup.   (vob_restore)
Remove a vob-tag from a region.   (rmtag)
Clean out a VOB database.   (vob_scrubber)
Create/modify a storage pool.   (mkpool)
Remove a storage pool.   (rmpool)
Rename a storage pool.   (rename)
Scrub the derived object and cleartext pools.   (scrubber)
List the pools associated with a VOB.   (lspool)
Change a VOB's feature level.   (chflevel)
Change the mastership of a VOB.   (chmaster)
Determine view and VOB server processes.   (albd_list)
Designate registered view and VOB storage locations. (mkstgloc)
List registered view and VOB storage locations. (lsstgloc)
Remove view and VOB storage location registrations. (rmstgloc)
Add an existing view or VOB to a new region. (mktag)
Set or determine a VOB's text mode. (msdostext_mode dump)
Get a listing of all owners of all VOB objects. (vob_siddump)
Create a multi-component VOB.
Fix VOB protections.
Lock or unlock a VOB.
Determine the VOB database schema version.
Enable/disable VOB auto-remounting after reboot.
Ensure nobody outside a specific group can even read a VOB's contents.
Determine the replica name of a VOB. (describe)
Link VOBs together. (ln)
Change protections on all objects in a VOB. (vob_siddump,vob_sidwalk)
List all MetaData types in a VOB.
Lock a VOB down to a couple of users.

 

Web
Back to the TOP
Install CC Web
Create a web snapshot view.
Configure CC web parameters.
Download an element without checkout.
Override/set the designated primary group.
CC web ccase_tools. (general)
Update a web snapshot view.
Rational Web Platform (RWP).
Change the default RWP HTTP port.





Create an attribute type.
Attributes are name/value pairs. The types are integer, real, time, string and opaque. The opaque type is used for arbitrary byte strings. The default types are:
CLI (NT & UNIX) string (no limit on length)
NT Type Explorer integer
xclearcase no default
Attribute types can be applied as widely or narrowly as desired. That is, you can apply an attribute type to a specific version of a specific element if desired. However, once the scope of the attribute type is defined and instances of it exist, the scope cannot be tightened. For example, a "once per version" attribute type cannot be changed to "once per element", if instances of it already exist. The default for all interfaces is to create an attribute type local to the current VOB.
In xclearcase, Metadata -> Attribute -> Attribute type... -> Type -> Create...
In NT CC Type Explorer, right-click on mounted VOB in NT Explorer and go to ClearCase -> Explore Types, double-click on attribute type and go to Type -> Create...
From the CLI:
  # ct mkattype [option(s)] attribute-name
Some common options:
-vty.pe integer, real, time, string or opaque   (see above for default)
-vpe -vpb -vpv (scope) Attributes can only be applied to elements, branches or versions respectively (default is all 3).
-enu.m Specify a comma separated list of permitted values.
-def.ault Supply a default value.
-glo.bal Allow the attribute to be used by other VOBs.
[ -gt | -ge ][ -lt | -le ] Allowed value ranges can be used for integer, real and time attribute types.
-sha.red Multiple CCMS sites can rmattr and mkattr on this type, but not if the object to which it is attached is mastered elsewhere.
NOTE: String values enumerated in the CLI need to be enclosed in double quotes which must be escaped with backslashes. String values enumerated in the NT Type Explorer or xclearcase don't need the quotes attached. In xclearcase, values can only be enumerated after creation and via Metadata -> Attribute -> Attribute type... -> attribute -> Type -> Describe. Unfortunately, in the NT and UNIX GUIs, enumerated values must be entered one at a time.
NOTE: If an attribute type's allowed range values are changed after there are already instances of that type, CC will not complain if those existing values are now "out of range". That is, validation only happens at the time of mkattr.

Back to the Table of Contents.





Modify an attribute type.
From the CLI, simply use the   -replace   option with the mkattype subcommand, replacing any values desired. There is apparently no way to do a replace from a GUI.
  # ct mkattype -replace [option(s)] attribute-name

WARNING!   If you do not use the options that were specified in the original mkattype, they will be replaced by default values with the exception of the scope options, ordinary or global.

Back to the Table of Contents.





Attach an attribute.
An attribute type must be created separately prior to assigning it to an element. If the value that the attribute is to be set to is a ClearCase variable, use the   \"$VARIABLE\"   construct. Attributes can be applied via triggers using the "mktrype -mkattr" subcommand. Attributes can be attached to almost anything in CC, including other metadata types.
In xclearcase, highlight the element to be modified and go to Metadata -> Attribute -> Attach to element ... It will prompt for the value after selecting the attribute type.
In NT, right-click on the element and go to Properties of Element/Version -> Custom, right-click in the large field and chose Add Attribute ... Unfortunately, in the NT version you must know the attribute type name apriori. If the name is unknown, go to the command-line in that VOB and type "ct lstype -attype".
On the command-line:
  # ct mkattr attribute-name \"value\" object-selector
Some common options:
-rep.lace Change an existing attribute to a new value.
-con.fig derived object Apply the attribute to all elements that went into a build.
-r.ecurse If applying to a directory, apply it recursively.
-v.ersion version-selector Apply it to a version other than selected by your view.
-default Use the predefined default value instead of providing one.

Back to the Table of Contents.





Remove an attribute from an element.
In UNIX xclearcase, highlight the element and go to Metadata -> Attribute -> Remove from version... or Remove from element...
In NT, access the properties sheet of the CC object. Go to the Custom tab, right-click on the attribute and select "Remove Attribute".
On the command-line:
  # ct rmattr attribute-name element
A useful option:
-ver.sion version-selector Specify a version other than selected by your view. For example, -ver '/main/{TESTED="False"}'.

Back to the Table of Contents.





Modify an object's attribute value.
In xclearcase, unknown if it's possible.
In NT, access the properties sheet of the CC object. Go to the Custom tab, right-click on the attribute and select "Change Value".
From the CLI, simply use the   -replace   option with the new value.
  # ct mkattr -replace attribute-name new-value element
Back to the Table of Contents.



Rename an attribute type.
All instances of the attribute type are automatically changed.
In xclearcase, unknown if it's possible. Changes made to the attribute type's name are ignored when OK is selected (as of CC 4.1).
In NT, open the Type Explorer under the VOBs tab of the ClearCase Home Base. Select the desired VOB and double-click on the "attribute type" folder. Right-click on the attribute and select Rename.
From the CLI:
  # ct rename attype:old-name new-name
Back to the Table of Contents.



Find objects with a certain attribute/value.
In UNIX xclearcase, Report -> Find query.
The find command is only available on the command-line in NT.
Versions:
  # ct find . -version "attr_sub(attribute,operator,value)" -print
Elements:
  # ct find . -element "attr_sub(attribute,operator,value)" -print
Branches:
  # ct find . -branch "attr_sub(attribute,operator,value)" -print
The attribute,operator,value set looks like: my_attribute,==,"this is a comment". For NT, skip the single quotes around the attribute-selector and escape the double quotes. Acceptable operators are: ==, !=, <, <=, > and >=. If a symbol such as < is used, the entire attribute selector must be enclosed in double quotes. The operators containing ">" and "<" can be used even if the values have been enumerated. In addition, they can also be used on strings. For all the variations on the syntax, see the query_language page in the CC Reference Manual.
One can act upon the results of the find command. That is, instead of the -print option, use the -exec option. As an example, change the attribute status="built" to status="tested" everywhere label BLD1.1 appears: On UNIX: # ct find . -ver "lbtype(BLD1.1)" -exec 'cleartool mkattr -replace status \"tested\" $CLEARCASE_XPN' On NT: # ct find . -ver "lbtype(BLD1.1)" -exec "cleartool mkattr -replace status \\\"tested\\\" %CLEARCASE_XPN%" If using the "cmd" executable to, say, copy files around, invoke it as "cmd /c copy ..." instead of simply "cmd copy ..." in the exec option's argument.
NOTE: Even though attributes can be attached to other objects, such as hyperlinks and VOBs, there is no direct way to query for them on those objects after they've placed there.

Back to the Table of Contents.





Change an attribute type's constraints.
An attribute can be applied to almost any object in CC. With respect to elements, it can be applied to the element itself, one of its branches and all of its versions. However, the ability to apply it to an element can be constrained to one of those element sub-objects. That is, it can be constrained to apply only to versions, only to branches or only to the element itself. There is no default constraint for all interfaces. If there are instances of the attribute type already in existence, the constraint cannot be tightened. For example, if an attribute type is created with the default of no constraints and then it is applied somewhere, one cannot change the constraint to "one per version" (or some other tighter constraint). However, the opposite CAN occur. One can always go from once per version, branch or element to "no constraint".
In xclearcase, Metadata -> Attribute -> Attribute type... -> select type -> Type -> Describe -> General (Cont'd)
In NT Explorer, right-click on VOB -> ClearCase -> Explore Types -> go to "attribute type" folder -> right-click on "attribute type" -> Properties -> Type Details
From the CLI:
  # ct mkattype -replace constraint attribute-name
The constraints are -vpe, -vpb and -vpv for one per element, branch and version respectively. No constraint argement means no constraints.

Back to the Table of Contents.





Create a branch.
Branches can be created three different ways:
1) Command line: The branch-type must exist prior to creating the branch. You can use the   -version   option to designate an element version other than that being selected by the current view.
  # ct mkbranch branch-type element-name
2) Set up a private branch. (NT only)
3) Automatically in a config_spec:
A view's config_spec file can be configured to automatically create a branch when a file is checked out. The branch point must be pre-determined by using a label on the version from which to be branch or by specifying a a version such as LATEST. If using a view profile, it will configure the config_spec automatically.
element * LABEL -mkbranch branch-type
To set up automatic creation of nested branches:
element * CHECKEDOUT
element -directory * /main/LATEST
element * /main/branch1/branch2/LATEST
element * /main/branch1/LABEL2 -mkbranch branch2
element * /main/branch1/LATEST -mkbranch branch2
element * /main/LABEL1  -mkbranch branch1
element * /main/LATEST  -mkbranch branch1
NOTE: I personally always have my directories as /main/LATEST. While versioning of directories is very important, from experience, branching of directories can be too confusing. The above example can be alternatively written:
element * CHECKEDOUT
element -directory * /main/LATEST
element * /main/branch1/branch2/LATEST
mkbranch branch2
element * /main/branch1/LABEL2
element * /main/branch1/LATEST
end mkbranch
mkbranch branch1
element * /main/LABEL1
element * /main/LATEST
For the above example, EOF can be used in lieu of "end mkbranch".
WARNING!   If using auto-mkbranch in a config_spec and you add an existing file to source control, it will correctly place that file's contents on the final branch in your tree (based on the -mkbranch rules), but the 0'th version on all intermediate branches, including main, will be empty. This is noted because it is a possible point of confusion. To see the new elements contents on other branches, simply merge to them.
See the following useful whitepaper from Rational on branching. The contents are an html file with associated gifs:   NT   UNIX
NOTE: The mkbranch operation can be triggered, but the trigger will not fire for creation of the main branch during mkelem.

Back to the Table of Contents.





Remove a branch.
  # ct rmbranch element-name@@/main/branch-name
Back to the Table of Contents.



Create a branch type.
In UNIX xclearcase, Versions -> Branch -> Branch type... -> Type -> Create...
In NT CC Type Explorer, right-click on mounted VOB in NT Explorer and go to ClearCase -> Explore Types, double-click on branch type and go to Type -> Create...
On the command-line:
  # ct mkbrtype branch-name
Some useful options:
-rep.lace Change the parameters of an existing branch type.
-glo.bal Declare it so that other VOBs can use it (see adminstrative VOB).
-pbr.anch Override the default to allow more than one branch of this name per element (not recommended).

Back to the Table of Contents.





Rename a branch or branch type.
Branch type:
All instances of the branch type are automatically changed. View config_specs and profiles referring to the old-name are not automatically updated.
In xclearcase, Admin->Branch type, select the type then Type->Rename.
In Windows, right-click on the VOB and select ClearCase->Explore Types. Enter the "branch type" folder, right-click on the type and select Rename.
From the CLI:
  # ct rename brtype:old-name new-name

Branch instance:

A single instance of a branch type can be renamed using chtype. For example, if you mistyped dev1.0 in your config_spec and it was really suppose to be dev1.1, you can simply correct your config_spec and change the branch name on an instance by instance basis.
In xclearcase version tree browser, highlight the branch to be changed then Branch->Change type.
In Windows, unknown if it's possible.
From the CLI:
  # ct chtype new-branch-name element@@old-branch-path
ex:
  # ct chtype dev1.1 foo.c@@/main/dev1.0
WARNING!   In a UCM environment, if the branch type is part of a UCM environment, see "Rename a project's Integration stream/branch". However, you can rename a development branch type without issue. After renaming the branch type, just be sure to rebase the stream and run "ct setcs -stream -tag view-tag" on any views associated with the stream.

Back to the Table of Contents.





Set up a private branch. (NT only)
"Set Up Private Branch" based on a view profile via ClearCase Home Base -> Branches or by right-clicking on the view in Explorer. A view profile must exist prior to branch creation.
NOTE: Setting up a private branch does not extend the rules currently in your config_spec, but overwrites them. Currently there is no way to nest private branches, they branch from main. That is, if you have a view profile that, say, automatically creates an integration branch off of main, and you want to set up a private branch off of that, using the "Set Up Private Branch..." menu option won't work properly. It will prompt you whether you want to associate the private branch with the existing rules or choose a different label point. If you choose to associate the private branch with the existing rules, the -mkbranch options for the integration branch will be replaced by the -mkbranch for the private branch, essentially branching the private off main. If you answer that you want to create the private branch from a label, it removes all references to "integration" branch and just has the private branch off main at the new label. The upshot of this is, if you want to have a branch off of the integration branch, the config_spec will have to edited by hand.

Back to the Table of Contents.





Finish a private branch. (NT only)
Finish Private Branch via ClearCase Home Base -> Branches or by right-clicking on the view in Explorer. Finishing a private branch will prompt whether you want to abandon the branch or merge it. If you choose to merge, it runs a findmerge for you. If the window comes up blank, it didn't find any. Since private branches are mandatorily associated with view profiles, the merge is automatically back to the integration branch or main, depending on what you set up during the view profile creation.
NOTE: When a view is dissociated from a view profile, the view's config_spec remains the same as the view profile. However, when you "Finish Private Branch...", the config_spec reverts back to that of the associated view profile.

Back to the Table of Contents.





Differences between CC and CCLT

Out of the box, CCLT is UCM only. However, just because it automatically installs a PVOB for you, you aren't forced to use UCM. It only has one PVOB (created at install) on one server. CCLT is snapshot views only.
CC features NOT included in CCLT (including associated commands, such as setview, rmdo, mkreplica, etc...)
Differences:
Things that did not change:
Interop between CC and CCLT.

Client Server
CCLT CCLT ok
CCLT CC 4.1+ ok
CC CCLT not allowed

Back to the Table of Contents.





Upgrade CCLT to CC
Check the latest manuals for an official procedure before using this one. More specifically, see the Installation Guide bundled with the release. The following procedure assumes you are going to use a registry server other than the current CCLT server. Ensure ALL view-private files are accounted for and files are checkedin. CCLT views cannot be used with Full CC.
1) Remove all views.
2) If running CC 5.0 or earlier, uninstall first.
3) Install Full CC.
4) Run the upgrade tool. It registers VOBs, tags VOBs, and changes some file protections.
  # ccase-home-dir\etc\utils\cclt2cc -w registry-password
Other options:
-v   vobtag1,vobtag2,... Don't upgrade all VOBs, just the comma separate list of VOBs.
-d   region Tag the VOBs in the designated region instead of the default.
-p   vobtag-prefix Unix only. Create VOB tags with the designated prefix. The default is "vobs".
5) Create new views.

Back to the Table of Contents.





Derived objects (general).
Derived objects (DOs) have three distinct parts; the DO, its data container a configuration record:
1) The DO appears as a view-private file in the directory in which it was created. This is just a pointer to the data container and not the actual object file.
2) The data container when initially created (unshared) is located in the view's storage area. If another view winks in the object, the data container is copied to a more permanent storage area within the VOB's storage area (shared). In either case the data container is not a VOB object or versioned. It is only a versioned object when a checkin is explicitly run on the DO. Note, a mkelem is not necessary on the DO, as the DO is already in the VOB database, just not versioned.
3) Configuration records (CRs) are created each time clearmake executes a build in which one or more DOs are created.

Derived objects can be referenced different ways:
1) simple name (if already local to view) -- ex: hello.o
2) view-extended naming -- ex: /view/view-tag/hello.o
3) VOB-extended naming -- ex: hello@@21-Dec.16:18.397
The unmbers at the end of the VOB-extended naming are the date and an ID unique to that date.

Back to the Table of Contents.





List derived objects.
The default is to list all DOs at a given pathname regardless of what view was used.
  # ct lsdo [derived-object]
A couple of the more useful options include:
-r.ecurse List recursively.
-me Restrict listing to DOs under your control.
-zer.o List unshared DOs with a reference count of 0.
-l.ong Show reference counts and the views that reference them as well.
The describe subcommand can be used to list DO versions that the lsdo cannot.

Back to the Table of Contents.





Remove derived objects (DO).
DOs and their data containers can be deleted independently, because a view may no longer need to reference a DO, but other views still need to get at that data container. Deleting a DO without rmdo decrements its reference count. The reference count of a DO can be determined with "ct describe". Shared is defined as being in a VOB storage area. Unshared is defined as only being in a view's private storage area. To ensure that all references to a DO are deleted, you need to combine an rmdo with a UNIX rm (or NT del) command.
1) Using UNIX mv (or NT move) or ct mv on a shared or unshared DO has no affect on the DO being a candidate for winkin or not. That is, the name seen in the view can be changed and the DO retains its CR and can still be winked in to another view under the original name.
2) Using UNIX rm (or NT del) will delete an unshared DO in the normal way along with its data container and CR.
3) Using UNIX rm (or NT del) on a shared DO will have no affect on the data container that has been promoted to the VOB.
4) A build that overwrites an unshared DO acts just like the rm (del) command in (2).
5) Using rmdo on a shared DO will delete the VOB data container and CR. Any version of the DO still in a view will become a simple view-private file.
6) Using rmdo on an unshared DO will not delete it or the container in a view's private storage area; only the CR. A subsequent ct ls command will list the DO as [removed with white out]. If this is the case, "touch" the DO and then "rm" it.
7) The CC "scrubber" command will delete shared DOs and data containers from the VOB's pool that have a reference count of 0. See the mkpool command for information on setting the pool scrubbing parameters.
8) See the view_scrubber command for the scrubbing of DOs from a view.

Removal of DOs can only happen on the command-line for both UNIX and NT. By default, the rmdo command only deletes one DO version for a given name. That is, there may be many DO versions of a DO, but rmdo will only remove the one that is in the current view.
  # ct rmdo DO(s)
Some useful options:
-a.ll Remove all versions of the DO regardless of reference count.
-zer.o Similar to -all, but only delete those DO versions with zero reference counts.
-bef.ore   date-time New in CC 2003.06.00. Delete DOs dated prior to a certain date-time.
-sin.ce   date-time New in CC 2003.06.00. Delete DOs dated since a certain date-time.

Date-time strings for the -before and -since options must adhere to date.time | date | time |now where:
date day-of-week | long-date
time h[h]:m[m][:s[s]] [UTC [ [ + | - ]h[h][:m[m] ] ] ]
day-of-week today |yesterday |Sunday | ... |Saturday |Sun | ... |Sat
long-date d[d]–month[–[yy]yy]
month January |... |December |Jan |... |Dec
Specify time in 24-hour format, relative to the local time zone. If you omit the time, the default value is 00:00:00. If you omit date, the default is today. If you omit the century, year, or a specific date, the most recent one is used. Specify UTC if you want to resolve the time to the same moment in time regardless of time zone. Use the plus (+) or minus (-) operator to specify a positive or negative offset to the UTC time. If you specify UTC without hour or minute offsets, Greenwich Mean Time (GMT) is used. (Dates before January 1, 1970 Universal Coordinated Time (UTC) are invalid.)

Back to the Table of Contents.





Configuration records (general).
A configruatoin record (CR) is a bill of materials generated by the clearmake, omake and clearaudit commands. Any time a DO is created a CR is written to that view's database. The CR is copied to the VOB database when/if the DO is winkedin or promoted. If the DOs span many VOBs, then each VOB will have a copy of the CR. A CR contains several sections (only the first two apply to clearaudit).
Header target, host info, time, view and initial working dir
MVFS objects each MVFS file read during the build (versioned & view-private)
Non-MVFS files explicitly mentioned by the makefile but not in CC
Variables and options values of make macros referenced by the build
Build script script executed by clearmake
Typically a makefile has a hierarchical structure. An invocation of clearmake on a makefile can cause multiple build scripts to be executed, thus creating multiple CRs. That is, a CR is associated with a build target, not a makefile. Moreover, when running a command such as "catcr", the output pertains only to the DO at hand. Be sure to use the -recurse option to get the full source tree.
Initially, the DO and associated CR are view-private. To speed up referencing the CR in the currrent view during subsequent builds, a compressed file called .cmake.state is stored in the directory in which the build was started. A subsequent winkin or CC versioning of the DO will cause the DO and CR to be promoted to the VOB.
NOTE:The CR of a DO does not contain environment information that may be relative to a successful rebuild of the object later in time, such operating system patches and packages.
WARNING!   The dependency checking that occurs to determine if an object can be winked into another view does not take into account other vital factors, such as the operating system that originally build the object. For example, if an object is built on Solaris and a subsequent build of the identical source files is conducted on HP, clearmake could errantly winkin the DO. To avoid this potential issue, add the following to your Makefile. In the example, target.o is dependent on OSVERSION, even though it's send to /dev/null. The example is decidedly UNIX, but the theory can be applied to any OS.
OSVERSION: sh=uname -r

target.o:
	echo $(OSVERSION) > /dev/null
	$(CC) $(CFLAGS) target.c
Back to the Table of Contents.



Winkin a derived object.
Normally a DO is winked-in via a clearmake build. However, DOs can be winked-in at any time via the winkin command. This is useful to access another view's DOs, in that DOs cannot be accessed via the normal version-extended pathname. Once the DO is winked-in, it is accessible locally using that view.
  # ct winkin derived-object
See the derived object general discussion for DO naming conventions.
Some useful options:
-pri.nt Only list what would have been winked-in.
-sib.lings Wink-in DOs created by the same build script that created the named DO.
-r.ecurse Walk the DO's configuration record, winking-in subtargets of the named DO.
-out Specify a new local name for the DO (mandatory for view-extended name wink-ins).
-nov.erwrite Override the default of overwriting any existing unshared DOs.

If you specify a shared DO while working in the view where it was originally built and there is still a view-resident data container for the DO in that view, the view-resident data container is scrubbed and your view will access the shared data container in VOB storage. This is equivalent to executing a view_scrubber command.
If you specify an unshared DO in your view, it is promoted to the VOB and then winked-in. The view-resident data container is scrubbed and your view will access the shared data container in VOB storage. This is equivalent to executing a view_scrubber -p command.
Note that view_scrubber is more efficient when a large number of DOs are to be processed in this way.

Back to the Table of Contents.





Use clearaudit.
The clearaudit command can be used to create an audit record of any executable that outputs into a VOB context. That is, it creates DOs out of any files that the executable generated. This can be useful for creating a CR of a UNIX make that uses CC objects. However, those new DOs, though available to most DO related commands, cannot be winked-in by a clearmake unless an explicit winkin command is run.
  # clearaudit -c "make [options]"
The clearaudit can also be used to audit the backup of VOB elements. The output of the tar will have a CR associated with it listing the versions of the saved elements.
  # clearaudit -c "tar cvf tarfile file(s)"

Back to the Table of Contents.





View a configuration record.
See configuration records for a description of CRs.
In UNIX clearcase, Building -> Display config rec.
In Windows GUI, unknown if it's possible.
On the command-line:
  # ct catcr DO
Some useful options:
-r.ecurse Display the CRs of DO subtargets as well.
-fla.t Similar to -recurse, but consolidates into a list of unique versions.
-uni.on Similar to -flat, but one report for all DOs listed on the command line.
-mak.efile Similar to -recurse, but display output in makefile format.
-wd List pathnames relative to the current directory.
-typ.e { f | d | l } Specify the version types to report: files, directories or links.
-l.ong Include kinds of objects and their comments in the listing.
-s.hort Restrict output to file system objects only.
-fol.low New in CC 5.0/2002. List the targets of symbolic links, not the links themselves.
-scr.ipts_only New in CC 5.0/2002. Restrict the listing to the header and build script.

Back to the Table of Contents.





Diff configuration records.
See configuration records for a description of CRs. Don't know if it's possible to diff CRs in UNIX xclearcase or a Windows GUI.
On the command-line:
  # ct diffcr DO-1 DO-2
Some useful options:
-r.ecurse Compares the DOs and their commom subtargets.
-fla.t Consolidate subtargets into a single unique listing.
-wd List pathnames relative to the current directory.
-typ.e { f | d | l } Specify the version types to report: files, directories or links.
-l.ong Include kinds of objects and their comments in the listing.
-s.hort Restrict output to file system objects only.
-nxn.ame Do not include version extensions when listing MVFS objects.
-fol.low New in CC 5.0/2002, list the targets of links and not the links themselves.

Back to the Table of Contents.





Create non-shareable derived objects.
New in CC 4.0, one has the ability to create derived objects that cannot be shared (winked-in) by any other view. Simply, it doesn't create the VOB database entry that other views would need to know if a derived object has been built in another view.
A view (dynamic only) can be configured to create non-shareable DOs at time of creation. The default for a new view is shareable unless overridden by sitewide defaults. Make a view's DOs non-shareable during creation:
From the NT GUI, the option is tucked away in the Advanced Options button on one of the pages in the creation wizard.
From UNIX xclearcase, the option is prompted for during view creation.
From the CLI, NT or UNIX, use one of the following options:
  # ct mkview [ -sha.erable_dos | -nsh.areable_dos ] ...

Make a view's DOs shareable after creation:

From the NT GUI, see the view properties sheet, Advanced tab.
From UNIX xclearcase, unknown if it's possible.
From the CLI:
  # ct chview { -sha.reable_dos | -nsh.areable_dos } view-tag

Toggling whether a view's DOs can be shared or not only affects DOs created in the future. Non-shared DOs can be subsequently shared by doing a "winkin" on them or by using "view_scrubber -p". Once a DO has been shared, it cannot be unshared.

Back to the Table of Contents.





CC/CQ non-UCM integration.
It doesn't matter if the VOB being integrated is being served from NT or UNIX. The integration tool described below will handle both. For either case, you need to be logged into the NT box as the owner of the VOB to be integrated. Only the VOB owner or higher can create triggers, which is what this integration does. CC must be installed on the CQ server to utilize this integration. CQ does not need to be installed on the CC VOB server. Any client workstation that will use the integration needs CC and CQ installed.

On the CQ side:
Create a new schema. Add the ClearCase package to your schema. Also be sure to add any ClearCase package updates, such as "Upgrade 1.0". Note, if using CC prior to 4.0, this portion is completed via the CQ tab on the CC side. See below.

On the CC side (NT only):
Go to Start -> Programs -> ClearCase Administration -> ClearQuest Integration Configuration. In the ClearCase tab, choose the VOB to be integrated and determine the integration properties. In the ClearQuest tab (prior to CC 4.0), choose the schema with which to integrate and select Update ClearQuest Schema.
Even though the CQ integration is bundled with CC, you need to tell CC that you want that functionality during install. If you don't see the CQ Integration Configuration in the ClearCase Administration menu, you need to update your CC release area and reinstall CC.

NOTE: Out of the box, CQ does not require a password. However, the CC integration tool does not allow a null string as the password. Go to the CQ Designer and set up password authentication.

Back to the INDEX.





Remove the CC/CQ non-UCM integration.
Start the ClearQuest Integration Configuration wizard via the ClearCase Administration startup menu. Select the VOB to be de-integrated and simply set the Checkout Policy and Checkin Policy to "Never Prompt...". The trigger(s) that were created in the VOB during the integration are dynamically removed.

Back to the INDEX.





Set CC/CQ non-UCM integration policy.
See CC/CQ non-UCM integration. The integration page sets the policy.
NOTE: The checkout policy is post-op. That is, there is no way to capture the CQ-record-id and do something with or to it prior to checkout. The unco and checkin policies are pre-op triggers.

Back to the INDEX.





ClearCase/DDTS integration: NT
NOTE: This integration must be done even if the VOB is located on a UNIX server because the setup.exe configures the triggers to run on NT. The setup.exe mentioned below requires administrative privileges. Inform the appropriate people that any users wishing to use an integrated VOB will have to have the following user environment variables set:
  BUGTRACK_PROXY_HOST   unix-server-hostname
  BUGTRACK_PROXY_USER   vobadm
These can also be set from Control Panel -> CRM integration GUI once it is installed (below). Also, they will need to add %ATRIAHOME%\bugtrack to their PATH environment variable. The PATH variable will probably have to be set by an administrator.

Create a directory in atria-home called cc_ddts_nt.
Copy the files from V3.x_release-area/architecture/bugtrack/nt_install to the the directory cc_ddts_nt. Let setup.exe install the trigger scripts in %ATRIAHOME%\bugtrack\install. It also installs the CRM GUI in the Control Panel, which can be used to immediately integrate VOBs for you. You can use it or the command-line vob_prep command to integrate. Any VOBs to be integrated must be mounted first.

  C:\> cleartool lsview
  C:\> cleartool setview any-view
  C:\> cleartool lsvob
  C:\> %ATRIAHOME%\bugtrack\install\vob_prep vob-tag(s)
NOTE: Setting a view from the NT CLI is only available in CC versions prior to 4.0.
In lieu of the above commands, the CRM Integration GUI (in the NT Control Panel) can be used.

NOTE: There is a bug in the NFS Maestro that sometimes generates the inexplicable error of "Invalid argument" when trying to find the VOB on a UNIX server during the integration. See the ERRORS for description of the work around.

Back to the INDEX.





ClearCase/DDTS integration: UNIX
NOTE: Even though VOBs may be on the UNIX server, NT clients wishing to use the integrated VOBs must also run their own NT setup locally.
NOTE: Users of the integrated system need to add the following to their path: $ATRIAHOME/bugtrack. If this user is new to CC, also ensure that atria-home/bin is their path. Ensure that /usr/tmp or the directory pointed to by the environment variable TMP is world writable.
Prepare the policy files for use by the integration:
  # cd $ATRIAHOME/bugtrack
  # cp ../ddts/policy_vars.sh .
  # cp ../ddts/local_policy.pl .
Each user of an integrated VOB should set the following environment variables. If the user is executing the checkout on the same server where DDTS is located, it isn't mandatory to use those variables; which cause an rsh to be executed instead of direct execution of the trigger scripts. However, if the administrator wants all users to execute the trigger scripts as a particular user, then they will have to set these variables even if on the DDTS server:
BUGTRACK_PROXY_HOST   host on which trigger scripts are executed (VOB server)
BUGTRACK_PROXY_USER   username under which to execute the trigger scripts
If not set, these variables default to the current machine and user.
NOTE: When checking out an element in an integrated VOB, the client system sends and rsh command to the VOB server "rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER getpolicy". The key point here is that each user of an integrated VOB needs to have the ability to rsh into the server as BUGTRACK_PROXY_USER and run commands. This normally requires a .rhosts file in the BUGTRACK_PROXY_USER home directory. A .rhosts file should be world readable and have the following "client user" pairing. In this example, the user "p29330" coming in from the machine "fgcj5.geg.mot.com" is allowed to run commands on "BUGTRACK_PROXY_HOST" as "BUGTRACK_PROXY_USER".
fgcj5.geg.mot.com  p29330
scm.geg.mot.com    p29330
scm.geg.mot.com    vobadm
scm.geg.mot.com    ddts
According to the literature, you should be able to put more than one space-separated user on a line if they are coming in from the same remote machine. However, I've found that on some servers it is necessary to place each "client user" pair on their own line, even if the client is the same for both users. The BUGTRACK_RSH_COMMAND environment variable can be set to use a login other than "rsh", such "remsh" if necessary. As a test, run the following command to ensure it returns a list of environment variables:
  # rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER getpolicy
If the above command fails with "permission denied", check the .rhosts file in the BUGTRACK_PROXY_USER's home directory, the existence of /etc/hosts.equiv, configuration of the /etc/pam.conf file and/or one of the following man pages: inetd, inetd.conf, rsh, in.rshd, hosts, hosts.equiv, pam, pam_unix, pam.conf, etc...
NOTE: Be sure to set the BUGTRACK_ADMIN variable to an approriate person in the atria-home/bugtrack/policy_vars.sh file. They will be the one to rcv mail if something goes wrong.
The VOBs to be integrated need to be mounted before running the vob_prep command.

Login as vobadm.

  # cd $ATRIAHOME/bugtrack/install
  # cleartool lsvob
  # vob_prep vob-tag(s)
The vob-tag(s) are a list of public VOBs on the system that the project configuration manager wants to integrate. Must get users to vob_prep their own private VOBs. Must list VOBs' full paths. Cannot pick subdirectories of VOBs, it's all or nothing. Can give multiple vob-tags on the vob_prep command-line.
NOTE: The atria-home/bugtrack/policy_vars.sh file governs when and if there is a prompt for a bug number when an element is checked out/in. This policy file is in affect for all integrated VOBs on the server unless an alternate policy file is designated. If you want a second VOB to have a different policy, have each user of the other VOB set an env variable called ALT_POLICY to the full path of the other policy file: ALT_POLICY=atria-home/bugtrack/other_policy.sh. Be sure to comment-out the snippet of code that tests for an ALT_POLICY file from the bottom of the alternate or you will get infinite recursion.

Back to the INDEX.





Suppress requests for DDTS bug numbers.
Create environment variables. The request for a bug number upon checkout AND checkin is default.
NOTE: For inexplicable reasons, setting the CO_BUGNUM and CI_BUGNUM environment variables in the policy_vars.sh file have no affect even though the file explicitly says that they do. Rational says that this was true in the past and that that statement will be removed in the future. Those variables must be set locally on each client machine using the integrated VOB.
NOTE: The actual values used to set the environment variables can be changed using the variable in parentheses. These, unlike the BUGNUM variables, can be set globally in atria-home/bugtrack/policy_vars.sh.
altogether TASK_BUGNUM 0 (BUG_NONE)
checkin CI_BUGNUM 00 (BUG_DEFAULT)
checkout CO_BUGNUM 00 (BUG_DEFAULT)
Back to the INDEX.




Force the entry of a real DDTS bug number.
The initial install of the CC/DDTS integration allows the use of a simple carriage-return in lieu of entering a bug number. To force the entry of a real bug number, set the BUGNUM_REQ_CO and BUGNUM_REQ_CI variables in atria-home/bugtack/policy_vars.sh on the VOB server to TRUE. The changes are picked dynamically. That is, the atria daemon doesn't have to be restarted.

Back to the INDEX.





Remove CC/DDTS integration.
The vob_prep command is located in atria-home/bugtrack/install.
  # vob_prep -deinstall vob-tag(s)
Back to the INDEX.




Create an element.
Before creating an element, there needs to be a proper element type already in existence. See "Set up/modify a trigger script" for a discussion on element types and supertypes. To work with elements, the parent directory needs to be in a checked-out state first. As a default, the new element is created in the checked-out state. When creating elements stored on a UNIX machine, make sure the names adhere to the standard UNIX naming conventions. If creating an element from a pre-existing file, it is necessary to copy the file into the VOB directory first, thus creating a view-private file. That is, the pre-existing file must be copied local before making it into a CC element.
For pre-existing files:
In xclearcase, File -> VOB object -> Create element from file.
In Windows, right-click on the the view-private file and select "Add to Source Control...".
From the CLI:
  # ct mkelem filename
For non-existent files:
In UNIX xclearcase, checkout the parent directory, deselect the parent directory, File -> VOB object -> Create element...
In NT Explorer, File -> New -> kind, right-click on the new view-private file and select "Add to Source Control...".
From CC Web, click on Add at the top of the page and it will prompt for the local path to the flat file.
From the CLI:
  # ct mkelem filename
In general, the supertype of a file will be assigned based on the rules in the default.magic file located in atria-home/conf/magic. However, that can be overridden with the "-eltype element-type option. Unfortunately, automatic eltype assignment cannot be overridden when using either a UNIX or NT GUI.
(Windows only) Prior to CC 4.1, your primary group must be listed in the VOB's group list. As of CC 4.1, if any group you are a member of is in the VOB's group list, you have permission to mkelem.
Some useful options:
-elt.ype   element-supertype Override the supertype the magic file would have automatically chosen.
-nco Creates empty /main/0 but does not check it out. Original is moved to *.keep.
-ci Create /main/1 and check it in automatically. See NOTE below.
-ci -pti.me Preserve the modification date of the pre-existing file. See the NOTE below.
-master Explicitly assigns mastership of the element's branches to the VOB in which it was created.
-mkp.ath New in CC 2003.06.00. Adds to source contol the view-private directories in the elements direct parental path. Previously this was only available from a Windows GUI.
NOTE: For the -ci option, the file must already exist. If the new element is empty, CC will complain about it being identical to predecessor (/main/0). If the new element is not empty, /main/1 will be created and checked in.
NOTE: While copying a file in NT or UNIX into a VOB directory as a view-private file, it's simple to preserve the original creation/modification date. However, there is no way preserve that date in CC. Once the element is created, a new time-stamp is applied and the old is lost forever. If absolutely needed, the new element could possibly be given an attribute with the original time-stamp for record keeping purposes. Yes, the -ptime option preserves the modification date, but only until the file is overwritten with a new version. Inspection of the element using describe, lshistory and other CC commands will not show a preserved original date :-(.
NOTE: The mkelem subcommand has no   -recurse   option. That is, if you want to check into CC a whole directory structure all at once, mkelem is not the command to use. Instead, use a "clearexport_ffile -r directory" out in the non-CC system to create a cvt_data file. Cd to the VOB directory where you want the new directory to go and run "clearimport -v" on it there.

Back to the Table of Contents.





Remove an element.
There is no way to delete an element from a GUI.
To remove an element forever, use the rmelem command. If the element being deleted is a directory, elements inside the directory will wind up in lost+found. No need to checkout the parent directory first, as rmelem removes the element from all versions of the parent. As of CC 5.0/2002, only the VOB owner or a privileged user can remove and element if there is any metadata attached.
  # ct rmelem element
The rmelem command removes directory history of the element and creates a history entry about itself. This means that comments can be attached to the rmelem itself via the   -c   option. The confirmation prompt can be bypassed via the   -force   option. However, as recommended by the CC Admin Manual, it is much better to just use the rmname command. The rmname command removes the reference to the element from the directory element. That is, it still exists for previous versions of this directory, but will not for versions thereafter. A rmname of a CC directory will obviously cause all of its subdirectories to be dereferenced as well.
NOTE: If using UCM, rmelem will remove the element's name from the activity change sets to which it belonged.

WARNING!   While base CC elements can be recovered from backups, there is no way to recover a UCM element and have it installed back into the UCM heirarchy.

  # ct rmname element-name
Use the &nbps; -nco   option if you don't want to check-out the parent directory first; which would need to be done. To restore an element that has be de-referenced using the rmname subcommand, use the "ln" subcommand. That is, if code.c has been removed from the current version of the local directory.
  # ct  ln  .@@/main/older-version/code.c  code.c
The older-version is that last version of the current directory in which the file "code.c" existed. An lsvtree of the current directory for different versions will tell you in which version of the directory the element was last present.
  # ct  lsvtree  .@@/main/version
See also "Remove a version of an element."

WARNING!   If running rmname in a UCM environment, ensure the element is not part of any activities not yet delivered or you will get "file not visible in view" and the deliver will fail. Open the element's version tree browser and look for versions on development branches that do not a Merge hyperlink to an integration branch.

Back to the Table of Contents.





Change an object's permissions.
Need to be at least the object's owner to change its permissions. Use the corresponding protectvob command when changing permsissions on a VOB. There is no way to change permissions on a view without recreating it.
On Unix xclearcase, Admin -> Element -> Change ? --or-- Report -> Describe -> ClearCase Object
On Windows, context menu option Properties of Element -> Protection
On the command-line:
  # ct protect options element(s)
-or-
  # ct protect options type:selector(s)
Options:
-cho.wn new-owner Change the owner of the object.
-chm.od permissions Change the permissions.
-chg.rp new-group Change the group of the object.
-r.ecurse Change protections recursively.
-fil.e | -d.irectory Restrict the recursive protection change.
NOTE: In Unix, initial permissions are set be the user's umask unless the element was created from a view-private file, in which case the permissions are base on those inherited permissions. On Windows, the permissions are set to 444 for files and 777 for directories.
NOTE: On Windows, there is no way to remove group read permissions on an element.

Back to the Table of Contents.





Rename an element.
Renaming an element is as simple as the UNIX mv command. But, only use it in a CC context or errors will occur. This command only works within a single VOB. If you want to move an element to a different VOB, use the relocate subcommand.
  # ct mv oldname newname
From the CLI, the parent directory must be checked out prior to changing the name of a file or moving it somewhere else. Once the parent directory is checked back in, the element will still show up as the old name in previous versions of that directory.
NOTE: If the element is currently checkedout to a view, CC will send a warning message that view private may need to be renamed as well, but will continue with the element rename anyway. However, I don't know what the warning is for. If the element is checkedout to the current view, the view private file is automatically renamed as well as the element itself. If the checkout is another view on a different branch, the other view will only see your element rename when the branches are merged. If the checkout is to a view on the same branch, the view private file doesn't get the rename, but the subsequent checkin proceeds without issue.

Back to the Table of Contents.





Link to another element.
If there is code common to several areas in CC, create an original and then create a hard-link to that one from other areas. The directory containing the linked element must be checked out prior to creating the link. Entire directory elements can be soft-linked (-slink option) in a similar way. It is recommended that relative paths be used, vice absolute, to avoid invalid links if one or another VOB mount point gets changed. Links can only be applied from the command-line, both in UNIX and NT.
  # ct ln path/original-name linked-name
-or-
  # ct ln -slink /another-vob/directory directory
When a hard-linked element is checked-out, all other names for that element will appear as "[checked out but removed]". I.E. There is only one view-private file no matter how names there are for it.
The   -slink   option can be used to create a soft-link to the original, but there are many restrictions on what can be done WRT check-outs, labels, etc...
NOTE: Cannot use hard-links across VOBs or on directory elements; must use a soft-link (-slink) in those cases.
NOTE: Once a hard-link is created, there is no way to tell the "original" from the newly created name for that element. I.E. There are truly the same element in all respects. The only way to determine if two names in a VOB are really the same element is to use the mvfsstorage or dump command.
NOTE: Unlike UNIX, if the other end of the link does not exist, DOS will not list the link via "dir". However, a "ct ls" will show the invalid link in both UNIX and NT.
NOTE: In UNIX, if you cd to a soft-linked directory and then immediately "cd ..", you will not be where you were before, but rather you will then be in the directory above the other end of the soft-link. This is not true for NT. If you cd to a CC soft-linked directory in NT, the route you took to get there remains part of your path and can be traversed backwards.
NOTE: Most ct commands as well as config specs DO NOT follow softlinks. A few exceptions, such as find, have -follow options.
NOTE: In the Windows CC Explorer, double-clicking on a symbolic link correctly invokes the correct executable only if the symbolic link end has the same extension as the original file. That is, the CC Explorer is using the native system to set the icons next to the file names. However, this isn't true for directories. Symbolic links to directories have the "unknown" file type icon next to them. If you double-click on it, CC Explorer will launch the NT Explorer and take you to the correct directory. Since it doesn't leave you in the CC Explorer, this can be a sore point for developers.
NOTE: As of CC 5.0, there is no way to run a query to find symbolic links.

Back to the Table of Contents.





Remove a reference to an element or symbolic link.
This command is useful if you want to remove the reference to an element in the current version of a directory element. This avoids having to rmelem, which deletes all versions of the element. It is also useful for deleting symbolic links to other elements without removing the original. The rmname can be abbreviated to "rm". As of CC 4.0, the parent directory does not need to be checked out first.
  # ct rmname element
-or-
  # ct rm softlink
Back to the Table of Contents.



Remove references to view related elements from a VOB.
Uncheckout an element that belongs to a missing view.

If an element is checked out in a view and that view is subsequently deleted without checking the element back in, the element becomes "stranded". That is, CC will tell you that the file is checked out to a certain view, but you see that the view no longer exists. Use the following commands to undo the checkout. Obviously, any changes made to that element are already lost. You will need the view-uuid of the the deleted view. The describe subcommand will list any objects in a checked-out state in the VOB and give the uuid of the view that owned the checkout. Alternatively, if the missing view still has a tag and that tag name is known, the lsview -l command will also give you the UUID.
  # ct describe -long vob:vobtag
-or-
  # ct lsview -long viewtag

  # ct rmview -all -uuid view-uuid
There is another way that is a longer way to accomplish this, but requires that the view be a snapshot and that only the loaded files are gone (the vws directory still exists somewhere). If these conditions are true, run the following commands to uncheckout the elements. In fact, doing this will essentially recreate the view, but without any view-private files (including the checkouts) that were in the now missing view root. The following are the Windows version of the command set.

This will place the missing "view.dat" file in the view's vws directory.
  # ccperl ccase-home\etc\utils\regen_view_dot_dat.pl

Create a dummy directory somewhere and place the regenerated view.dat there.
  # mkdir C:\temp\tempview
  # copy vws-path\view.dat  C:\temp\tempview

Update the view and then perform the uncheckouts in the normal way.
  # cd \temp\tempview
  # ct update
Back to the Table of Contents.



Merge elements.
Updated: 09/19/06
Note: binary elements can be merged, sort of. If an element is of a type, such as "file" or "compressed_file", that cannot be diffed nor merged like an ASCII file, the "from" version will simply overwrite the destination version. However, that's only true if it's a trivial merge. If both versions have changed since the base contributor, the operation will complain that the files cannot be merged automatically. If given the option, skip the file and merge manually later. That is, don't try to merge binary files. Complete the merge by skipping those types of files. Then, checkout the binary in the destination view and copy the "from" version over the top of the checkedout version. If desired, an element type can be created using the "-mergetype never" option that states that these files are never to be merged, which makes the merge operation smoother, knowing that you're going to merge those files manually later.
However, new in CC 7.0, an element type can be created with "-mergetype copy", but it only works for UCM deliver and rebase merges.

Findmerge
The findmerge subcommand can be used to just look for files that may need merging. If it finds any, it will create a file in the local directory called findmerge.log.date. The contents of which will be the correct command(s) to use if merging is desired.
NOTE: If the commands in the findmerge.log.date-time file are used to perform the merge, because the versions to be merged are listed explicitly, another search will not be performed even though the commands are written as "findmerge".
  # ct findmerge element -fversion version -print
ex: ct findmerge word.doc -fversion /main/working_branch/LATEST -print
Some useful options:
-fta.g view-tag Look at the version selected by another view.
-fve.rsion version-selector To select a version marked by a tag.
-fla.test Select the LATEST version on the current branch. Useful if the checkedout version was checked out unreserved.
-fcs.ets activities (UCM only) Consider versions in the listed activities.

Merge If the versions to merged are known, the merge command can be used explicitly. For both types, the element "from" version is that selected by your view.
  # ct merge -to element -version version(s)
Some useful options:
------  
-query Start merge automatically and query to resolve conflicts.
-abo.rt Start merge automatically. Abort and roll-back if conflicts arise.
-qal.l Query on every merge.
------  
-nda.ta Create merge hyperlink, but don't actually merge.
-nar.rows Do merge without creating the merge arrow.
------  
-g.raphical Perform merge graphically. Merge result is editable on the fly.
------  
-out view-private-file Merge to a file other than the "to" version. No merge arrow recorded.
-opt.ions   "pass-through-options" Merge can pass through options, such as -blank_ignore, to the merge tool See cleardiff for a list.
See below on how to do selective and subtractive merges. If interested in customizing the GUI, see the man page or CC Ref Manual page cc.icon for matching file types to bitmaps.
In UNIX, merges can also be initiated by selecting an element in xclearcase, going to its Vtree Browser and then clicking on the Merge button (second from right in CC 3.2.1) or by going to the Version -> Merge menu.
In NT, merges can also be initiated by right-clicking on an element in the Version Tree Browser and selecting "Merge to...". When the target cursor appears, click on the "to" version. If similar merges are to be done regularly, time can be saved by setting up a Merge Manager session. The Merge Manager can be started via ClearCase Home Base -> Branches. Once the "findmerge" is complete, File -> Save As... the session. Next time you start Merge Manager, simply Merge -> Refresh Elements List, or hit F5.

Merge types:
Trivial - Nothing at all happened to one contributor.
Automatic - Only one contributor has changed for any given chunk of text.
Non-automatic - Cannot resolve conflict without human intervention.

Some shops choose to disallow automatic merges, because while the merge algorithm is very sophisticated, it isn't infallible.
Merging does not end a branch and can be in either direction. To "undo" a merge, simply uncheckout the "to" version. Therefor, it is always a good idea to test the merge results before checking in. A successful merge will leave a view-private file in the current directory called element.contrib. Checkin is not performed automatically and there is no .contrib file for directory merges. If it was a directory merge, check the directory in immediately so that only changes due to the merge are part of the changes to that directory version.

WARNING!   If doing a directory merge and separate branches have files of the same name but are actually different elements, the merge will rename the -from version to element.uuid.

Merges can be done in a selective or subtractive manner. These type merges can only be done from the command-line (with the exception of a single version selective merge) and merge arrows are not recorded, as a merge arrow implies a cumulative merge. Examples:

Select a single version.
  # ct merge -to element -insert -version version-selector
ex: ct merge -to foo.c -insert -version /main/bug_fix2/4
Select a range of versions.
  # ct merge -to element -insert -version from-version-selector to-version-selector
ex: ct merge -to foo.c -insert -version /main/bug_fix2/2 /main/bug_fix2/6
  If you want the range from versions 2 to 6, but not version 3, you must do two merges.
Exclude a single version.
  # ct merge -to element -delete -version version-selector
ex: ct merge -to foo.c -delete -version /main/bug_fix2/4
Exclude a range of versions.
  # ct merge -to element -delete -version from-version-selector to-version-selector
ex: ct merge -to foo.c -delete -version /main/bug_fix2/2 /main/bug_fix2/6
To determine the changes that took place for any given merge destination, use the annotate command. It writes a view-private file called element.ann.
  # ct annotate element

Merge Manager
CC Windows has a GUI called the Merge Manager that will conduct a findmerge type operation. As of CC 5.0/2002, clearmrgman is available from the CLI on both UNIX and Windows. It can be used for UCM deliver and rebase as well as base CC merges. It will start the Merge Manager GUI.
  # clearmrgman options
The base CC clearmrgman has many of the same options as "merge" and "findmerge".
-del.iver   [ -to target-view-tag | -tar.get stream-selector ] Deliver to the specified view or stream.
-reb.ase   -str.eam stream-selector Rebase the specified stream.

XML merge
New in CC 5.0/2002, xmldiffmrg facilitates the comparing and merging of XML elements.
  # xmldiffmrg operation
Options:
-xvi.ew | -xco.mpare | -xme.rge Must specify an operation for xmldiffmrg to perform.
-visible_blank White-space characters are made visible by alternate glyphs representing the white space.
-blank_ignore Ignores white-space in white-space-only nodes. Can be used with -visible_blank.
-hst.ack Stack the panes horizontally. (default)
-vst.ack Stack the panes vertically.
-out   filename Specify an output file for the merge result.
-to   to-version Specify the version extended file that is both a contributor and merge result.
-q.uery Prompts you to proceed with every change. Changes in the to-version are still automatically accepted.
-abo.rt Merge only if completely automatic.
-qal.l Query the user for every change including those in the to-version.
-enc.oding   { utf-16 | utf-8 | iso-8859-1 | ascii } If an output file is generated, use the specified encoding type.
-bas.e   version-selector Specify a base selector other than the one that would have been chosen automatically.

Back to the Table of Contents.





Change an element's type.
The element type to which it is being changing must already exist.
  # ct lstype -eltype
  # ct chtype -nc new-element-type element
This command can take awhile. For intsance, if you change from text_file to compressed_text_file and you have many text files, the system will immediately go through and compress all the data containers. Conversely, if changing from a type, such as text_file, to a user-defined type based on the supertype text_file, the command will complete instantly.

Back to the Table of Contents.





Move an element between VOBs.
This includes entire directory trees as well. Do not use this to move elements within a VOB; use "ct mv" instead. You cannot move UCM elements between VOBs.
  # ct relocate element(s) /target_vob-tag/path
Options:
-f.orce Suppress the default confirmation step.
-quall Ask for confirmation for every relocated borderline element (such as linked elements).
-upd.ate Run in update mode. Does not remove originals.
-log   logfile Record the transaction in a file other than the default relocate.log.date-time

*** Must be VOB owner or root of both VOBs.
*** Relocate will do the checkout of the target directory for you. However, you will get an error if the destination directory is already checked out to another view.
*** The ownership and permissions do not change during relocate, regardless of the username and umask of the user executing the relocate.
*** This command will not overwrite existing elements of the same name in the target VOB; you will get the error "already exists in the target-dir". If you want to create new versions of the target elements and/or leave the original elements in the original VOB, use the -update option.
*** If there is a collision with Metadata, relocate will rename the new Metadata type with a numbered extension. For example, if the label type BUG_FIX_1 already exists in the target VOB, the newly transferred label type will get named BUG_FIX_1.1, which may cause confusion.
*** Disable any triggers from both VOBs that might impede the checkout/in of the elements.
*** Ensure the elements to be relocated are not locked.
*** The relocate command does not handle view-private files. Of the three types: a) ensure all elements are checkedin (from any view) otherwise relocate will fail, b) generic view-private files need to be moved or removed and c) DOs are quietly deleted (unless they are versioned). Search for view-private files in every view via:
  # ct lsprivate -tag view-tag -invob /vob-tag/path
If view-private files become stranded during the relocate, they can be recovered. The recovered view-private files are placed in the view's lost+found directory in the view-storage area .s subdirectory. A view's lost+found directory doesn't exist until it's needed.
  # ct recoverview -synchronize view-tag -vob vob-tag
*** Relocate has the following affect on symbolic links. The "in" and "out" refer to whether an end of a link is in or out of the relocate selection set. View-private UNIX links are simply ignored. Any UNIX links pointing into the selection set will now be invalid. Any UNIX links pointing out of the selection set will be lost.
Link type original/linked-end notes
hard in/in The hardlink will be recreated as expected.
hard in/out The hardlink will be split, one data-container in each VOB. Each element will still point to each other via a new HyperSlink hyperlink.
soft in/in The softlink will be recreated as expected.
soft in/out The data-container is moved. The end in the original VOB now points to the wrong place.
soft out/in The data-container is not moved. The end in the new VOB now points to the wrong place.
*** Relocate will fail if the original VOB is attached to an AdminVOB in which Metadata types are locked.
*** Relocate will fail if the original VOB's types are CCMS mastered elsewhere. If the relocated elements are to be replicated as well, the target VOB will have to be created manually at the other site(s). If the relocated elements are NOT to be replicated, when the relocate command is complete, delete the RelocationVOB hyperlink from the originial VOB. It will also fail if the target VOB is a replica whose main branch type is mastered elsewhere.
*** If a relocate command aborts for some reason and you never get around to actually completing the relocate, the original VOB will still have a RelocationVOB hyperlink erroneously attached to it.
*** Relocate can be stopped and restarted, provided that you: DO NOT release the locks set automatically by the relocate command, DO NOT modify elements in the relocation set, and DO NOT record your answers to -quall the first time through. The final phase, removing elements from the original VOB, is not restartable.
*** Relocate can be run in an update mode (-update). Update mode does not lock the originals, does not remove the originals, does not create a symbolic link from the originals, will relocate non-locally mastered elements and does not checkout or modify the source directory. Also, update mode will not update the copies if objects have been removed from the original since the last update; I.E. rmver, rmbranch, rmelem. Update only creates objects, it does not remove them. If the removal on the original was actually a replacement, update will fail. For instance, if a branch is removed from the original and then rebranched from a different point, the relocate will fail to create the new branch because the old one still exists on the destination element. To get around this, simply remove the destination element in entirety and let relocate recreate it. One cannot switch from using update mode to a regular relocate. If after running updates one wants to now totally move the elements, delete the destination elements and run relocate as if for the first time. Finally, one cannot make changes to the desintation elements until you've stopped using the originals.
*** The relocate command will remove the originals if not run in update mode. It will create a soft symbolic link from the original to the new VOB to preserve the namespace in the original VOB.
*** The relocate command will preserve the relationship of bi-directional hyperlinks. It will not update uni-directional hyperlinks whose target is inside the selection set. It will update uni-directional hyperlinks that originate inside the selection set.

MultiSite
*** Running relocate in a CCMS environment takes a few more steps than just relocating the elements. The following is an un-tested set of steps that would most likely need to occur to preserve mastership across the relocate. The mastership of elements is irrelevant. The mastership of metadata can probably be cleaned up later on an as needed basis, but could be included in the scripts mentioned below if desired. The most important part of mastership that needs to be transferred is branch mastership.
1) Have all remote sites send out last minute, manual sync packets and then have them lock the VOB to be split.
2) At the local site, after importing any last minute sync packets, run a script that makes a list of the masterships of all branch types and branch instances throughout the directory tree to be relocated.
3) At the local site, create a new empty VOB and run the relocate in the normal way.
4) Create replicas of the new VOB for all sites involved.
5) At the local site, run a script that resets the masterships to the way they used to be.
6) At the local site, generate sync packets that contain the changes.
6) Send the replicas and sync packets of both the old and new VOBs to all sites.
7) Have all remote admins import the new replica VOB, unlock their old VOBs and perform a manual import of the sync packets for both VOBs.

Back to the Table of Contents.





Diff two text elements.
In UNIX xclearcase, hightlight an element and go to Versions -> Diff.
In Windows you can run a graphical compare by right-clicking on an element and choosing either "Compare with Previous Version" or "Compare...".
From CC Web, select the check-box next to an element and click on Compare at the top of the page. It automatically diffs with its predecessor.
From the CLI: ct diff
The diff subcommand can diff between text or directory elements in the same view or in different views. The following are a few of the permutations. See the CC Reference Manual for a full listing.
  # ct diff element element@@/main/branch/LATEST
  # ct diff -predecessor element
  # ct diff -graphical element /view/view-tag/element
Note that diff can only be used in a VOB context.

cleardiff
A cleardiff will give the same output as a simple diff command, but it has more formatting options. It cannot diff directory elements and does not have a -graphical option. The two files being diff'ed do not have to be in CC.

  # cleardiff element-version1 element-version2
xcleardiff
The UNIX only, stand-alone command xcleardiff utilizes xcompare and xmerge. It can be invoked by itself or via a "diff -graphical", "merge -graphical" or "findmerge -graphical". The font and colors can be customized. See "schemes" in the CC Reference Manual.
  # xcleardiff element-version1 element-version2
Some useful options:
-b.lank_ignore (diff) Do not display differences in blank lines when diff'ing.
-col.umns   n Divide n by 2. Default n is 80; 40 chars per column.
-tin.y (diff or merge) Use smaller fonts.
-vst.ack (diff or merge) Display the diff'ed files stacked vertically (default is horizontal).
-out (merge) Specify a checkedout version or system file (required).
-f.orce (merge) Overwrite the output file, if it already exists.
-bas.e   base-pname (merge) By default, xcleardiff does not calculate a base contributor.
-q.uery (merge) No automatic merging for non-trivial merges.
-qal.l (merge) No automatic merging at all. Automatically set if base not specified.
-abo.rt (merge) Abort if conflict arises. Used when called from a script.
-pause (merge) Do automatic merges, but pause for confirmation after each change.
-win.dow New in CC 2003.06.00. Disply the output in a separate difference window.

See also cleardlg on NT.

Back to the Table of Contents.





Remove a merge arrow from an element's version tree.
The following subcommand will remove the merge arrow that appears in an element's version tree. It does not affect either version of the element that was merged.
  # ct rmmerge from-version to-version
Back to the Table of Contents.



Remove a version of an element.
The rmver command destroys information irretrievably. It cannot remove a previous version of a file that is currently checked out, nor can it remove an interesting version: labeled, branch point, merge point, etc...; unless the appropriate option is used.
Delete uninteresting versions.
  # ct rmver element-name
Delete a specific version.
  # ct rmver -version /main/bugfix/5 element-name
Other useful options:
-f.orce don't ask for confirmation
-xbr.anch remove even if branch point, all version on the branch are removed also
-xla.bel remove even if labelled
-xat.tr remove even if attribute attached -xhl.ink remove even if hyperlink attached
-dat.a only delete the data container leaving the database intact, explicitly invokes the above listed -x options
-vra.nge specify a range of versions
NOTE: The rmver subcommand does not actually recover disk space, but merely marks that version as removed. This is not true for whole copy types though. History information is removed in both cases.

Back to the Table of Contents.





Create a directory element.
In Windows, right-click on the parent directory and choose Open. Use File -> New -> Folder to create a view-private directory. Then right-click on the new directory and "Add to Source Control...".
In xclearcase, click on the Shell button and use the command-line.
On the CLI, simply use the CC equivalent of the UNIX mkdir command. The directory will be created in a checkedout state unless the   -nco   option is used.
  # ct mkdir directory-element
or
  # ct mkelem -eltype directory directory-element
For each method, the parent directory must be checked-out first. Unlike UNIX, there is no associated "rmdir" command. Must use the rmelem to delete a directory element. Any contents of a deleted directory element will end up in the lost+found directory.
Options:
-master New in CC 2003.06.00. The replica in which element is created will explicitly master the main branch.

NOTE: Creating a directory element from an existing view-private directory only works in a Windows GUI. I.E. You will get the following error message from the CLI: Can't create directory element because ... already exists. If you need to create a directory element from the command-line and it already exists as a view-private directory or is out in the system somewhere, use the clearexport_ffile and clearimport commands. See "Import large amounts of data" for more information on that process.

Back to the Table of Contents.





List details about the contents of an element version.
Output is written to a view-private file element.ann.
  # ct annotate -long -ndata element
Some useful options:
-nda.ta Use when dealing with element types other than text.
-nhe.ader Suppress the header and output only annotated text lines.
-out Use to send output to a file other than element.ann. Use a dash "-" as the output filename to send to standard out.
-rm Show deleted lines.
-a.ll Show changes no matter what branch. That is, changes made to branches that don't affect the current version.
-fmt   format-string Format the output. See fmt_ccase in the CC Reference Manual.
-rmf.mt   rm-format-string New in CC 2003.06.00. Specify a format for deletion annotations. The default format is "DEL %Sd %-8.8u | ".

Back to the Table of Contents.





Checkout an element.
In Windows, right-click on the file.
In xclearcase, left-click on the file to highlight it then go to the Versions menu.
From CC Web, select the check-box next to the element(s) and click on Checkout at the top of the page. You can only apply one comment to all elements checkedout with the same Checkout command.
From the CLI checkout can be abbreviated to co. This will checkout the version of the element selected by the current view.
  # ct co element
Checkouts are recorded both in the view and VOB databases.
Some options:
-ver.sion Checkout a specific version not necessarily selected by the current view.
-bra.nch branch Checkout the LATEST version on the specified branch.
-out file Checkout an element under a different name.
-unr.eserved Checkout an element allowing others to check it out also.
-unr.eserved   -nma.ster Checkout even if the local site doesn't master the branch.

WARNING!   When merging in the changes from the checkout from a previous version, the Merge hyperlink will erroneously point to the version just prior to LATEST.

NOTE: A single view can have only one checked out version of an element at a time. Files can only be checked out if you have write permission to the view's storage directory. At most, there can be only one reserved checkout of an element.

WARNING!   While only the checkout owner can check an element back in, if two users are using the same view, they can modify any element checked out to that view (file permissions permitting).

  # ct co -nc -unreserved element
  # ct co -version element@@/main/version
  # ct co -branch /main/bug_fixes element
  # ct co -out element_test element
Files are normally checked out reserved. That is, only the person who checks it out can check it back in. The element can also be checked out unreserved, which means that someone else can check it out too. However, if more than one person has it