One can use ct diff as in:

ct diff -pre /path/to/file

Use the xclearcase tool (without any parameters) to launch an explorer-type graphical tool; you can select files and view their versioning tree. Alternatively, (to just view the tree for a particular file you're interested in) use:

xclearcase -vtree /path/to/file

ct ls -l some/file

ct lshistory some/file

ct lshistory -long some/file

ct lsview

First of all you need to "enter" that particular view. You should know by now that there are two ways to "enter" a particular view (say view some-view-name):

• by using ct setview some-view-name which gives you a new shell (this is really the old way)
• by cd-ing into the /view/some-view-name directory (which is the presently recommended way to do it). To cd there, the some-view-name directory needs to be created first and the way to do this is as a side effect of a ct setview command invocation as described in NB2 here

Once you're in that view (whatever "in" may mean) you simply do:

ct catcs

$ ct catcs
element * CHECKEDOUT
element /vobs/ASC_BUILD/... ANTBUILD
element src/db/... .../dbdev_br/LATEST
element * /main/LATEST -mkbranch dbdev_br 

  $ ct catcs
  element * CHECKEDOUT
  element /vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties .../dbdev_br/4
  element /vobs/ASC_BUILD/... ANTBUILD
  element src/db/... .../dbdev_br/LATEST
  element * /main/LATEST -mkbranch dbdev_br

$ tree  /view/mperdike_dev_view/vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties@@
/view/mperdike_dev_view/vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties@@
├── ANTBUILD
└── main
    ├── 0
    ├── dbdev_br
    │   ├── 0
    │   ├── 1
    │   ├── 2
    │   ├── 3
    │   ├── 4
    │   ├── 5
    │   ├── ANTBUILD
    │   └── LATEST
    └── LATEST

Use the ct ls -l command.

Example output:

$ ct ls -l /view/mperdike_dev_view/vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties
version                /view/mperdike_dev_view/vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties@@/main/dbdev_br/4           Rule: element /vobs/ASC_DB_WEB/src/db/www/ant-buildsystem/ivy-filesystem-resolver-root.properties .../dbdev_br/4 

The despicable, cold-war era, shitty "product" ClearCase somehow thinks that text files cannot include lines extending 8000 bytes. When you try to commit a minified Javascript library this "feature" will rear its ugly head:

$ ct mkelem -ci -nc jquery-3.2.1.min.js
Created element "jquery-3.2.1.min.js" (type "text_file").
Created branch "dbdev_br" from "jquery-3.2.1.min.js" version "/main/0".
text_file_delta: Error: "jquery-3.2.1.min.js" is not a 'text file': it contains a line exceeding 8000 bytes.
Use a different type manager (such as compressed file).
cleartool: Error: Type manager "text_file_delta" failed create_version operation.
cleartool: Error: Unable to check in "jquery-3.2.1.min.js".

To fix the above, use:

cleartool chtype compressed_file jquery-3.2.1.min.js

$ ct mkelem -ci -nc jquery-3.2.1.min.js
cleartool: Error: Entry named "jquery-3.2.1.min.js" already exists.
cleartool: Error: Unable to create element "jquery-3.2.1.min.js".

$ ct ci -nc jquery-3.2.1.min.js
Checked in "jquery-3.2.1.min.js" version "/main/dbdev_br/1".
        

cleartool setview mperdike_dev_view

    ct co <parent directory>
    ct mkdir dirname
    ct ci <parent directory>

If it's a regular file:

    ct co <parent directory>
    ct mkelem -ci file
    ct ci <parent directory>

If it's a symlink:

      $ ct co -nc .
      Checked out "." from version "/main/branchname/6".
      $ ct ln -slink ../../some/other/filename filename
      Link created: "filename"
      $ ct ci -nc .
      Checked in "." version "/main/branchname/7"

See the following SO question of mine:

• working in /vobs/some/path versus /view/view-tag-name/vobs/some/path

Bottom line is that ct setview is evil and you can simply work in /view/view-tag-name/vobs/some/path. I've also confirmed that with colleagues. The only caveat is that I've only tried this with dynamic views (not snapshots).

The clearfsimport makes working with the ClearCase abomination borderline bearable. It works both for the initial importation of some arbitrary directory structure (and propertly handles symlinks too) and also for subsequent updates. In the below incantation assume that:

• the current directory is some ClearCase dynamic view and we are right above the directory foo that we're trying to import
• the path /tmp/foo is just a random filesystem directory, outside of ClearCase

clearfsimport -c 'optional comment' -recu -nset /tmp/foo/ . 

For some inscrutable reason the -nset flag is essential. For more see here.

To perform an update (after the initial import) simply additionally use the -rmname flag in the above incantation:

clearfsimport -recu -nset -rmname /tmp/foo/ .

Following the above, I have been advised (by CfA people) to also issue the following (after doing a cd to foo):

ct protect -chmod ug+w $(find -type d)

Note that I've only tried the above in dynamic views, not snapshots.

ct pwv                 ; prints working view
ct ls -l
ct ls -view_only
ct ls -rec -view_only
ct lshistory
ct lsprivate -co
ct unco
ct des .
ct lsco
ct lsco -dir .
ct lsco -recu foo
ct lsco -me -recu
ct mkelem -mkpath dir-or-source-file
ct diff -diff -pre Makefile
cat Makefile@@/main/dbdev_br/1

$ ct co .
$ ct rm foo
$ ct ci . 

rm is an alias for rmname.

At this point in time it is not clear to me how rm / rmname is different from ct rmelem. Our ClearCase resident expert suggested using ct rm/rmname and that indeed does the trick (recursively)

My impression at the moment is that rmelem is of a more permanent nature whereas with rmname you maintain history.

ct des . | grep check

ct lsco -dir .

In the current directory only (non recursively):

ct ls -l | grep private

ct ls -view_only

Recursively, under the current directory:

ct lsprivate .

ct ls -view_only -recurse

NB: some of the above incantations may return both view-private and checked-out objects.

Say you wish to remove directory dir-to-remove in present directory.

ct co -nc .
ct rmname dir-to-remove
ct ci .

ct rmview -f -tag mperdike_dev_viewsnap
      

From what I observed this deletes the (server-side) "view storage directory" that's provided with the -vws in the ct mkview invocation for a snapshot view. I believe I had to delete the "snapshot view directory" (in my local file system) manually.

ct mkview -sna -tag mperdike_dev_viewsnap -vws /data/VIEWS/mperdike_dev_viewsnap.vws -host serverhostname -hpath /data/VIEWS/mperdike_dev_viewsnap.vws -gpath /data/VIEWS/mperdike_dev_viewsnap.vws /export/mperdike/cc-snap-views/mperdike-dev-viewsnap

• -sna
  this flag triggers the creation of a snapshot view (as opposed to a dynamic view)
• the -tag, -hpath, -gpath arguments have the same meaning as in the creation of a dynamic view
• -vws
  this is an argument that uniquely applies in the case of the snapshot views only. It provides the "view storage directory" on the server. In the case of dynamic views the same information is passed not through an optional argument but as the mandatory last argument (described in the documentation as "dynamic-view-storage-pname" or "dynamic-view-pname")
• the last argument (/export/mperdike/cc-snap-views/mperdike-dev-viewsnap in the above incantation) is the location on my local filesystem where the snapshot view will be created. I have seen this being referred in the documentation as "snapshot view directory"

Following the creation of the snapshot view, it is of course empty and one has to edit the config spec. In my case, I already had a dynamic view and just wanted the snapshot view to mirror the dynamic view, so I did a: ct catcs in the dynamic view and then used ct edcs in the snapshot view to copy (verbatim) all rules (selection rules) that appeared in the dynamic view config spec. Following that, I added (in my case) a single load rule specifying the vob I wanted to load.

So in my case, the dynamic view config spec is:

$ ct catcs
element * CHECKEDOUT
element src/db/... .../dbdev_br/LATEST
element * /main/LATEST -mkbranch dbdev_br 

$ ct catcs
element * CHECKEDOUT
element src/db/... .../dbdev_br/LATEST
element * /main/LATEST -mkbranch dbdev_br
load /vobs/ASC_DB_ADMIN/ 

Once the snapshot view's config spec was saved, stuff started to get downloaded. I noticed that in addition to the vob I specified some additional ones were downloaded (presumably due to some dependency?).

ct mkview -tag mperdike_dev_view -host serverhostname -hpath /data/VIEWS/mperdike_dev_view.vws -gpath /data/VIEWS/mperdike_dev_view.vws /data/VIEWS/mperdike_dev_view.vws

• -host
  the -host argument should provide the server where CC runs
• -tag
  the -tag argument provides the view tag (i.e. a friendly name)
• the -hpath and -gpath arguments as well as the last mandatory parameter take their names (as a convention I guess) from the -tag argument and basically specify the view storage location on the server. On my machine the /data/VIEWS directory is mounted on an NFS filesystem:

  $ df -P -T /data/VIEWS | tail -n +2 | awk '{print $2}'
  nfs 

alias ct=cleartool
alias ci=checkin
alias co=checkout
alias uco='uncheckout'
alias xcc='setenv LANG en_US; xclearcase &'
alias cmake='clearmake -C gnu MAKE=clearmake UIROOT=/vobs/ASC_BUILD/src'
alias ctmv='ct setview -exec "newgrp ccase" mperdike_dev_view'

NB: Regarding the last of the above aliases (ctmv), it seems there is no actual need to use setview. setview spawns a second shell and you are expected to navigate to, e.g. /vobs/ASC_DB_ADMIN to do your work. Instead, one can simply navigate to (in my case) /view/mperdike_dev_view/vobs/ASC_DB_ADMIN and have access to the exact same information without having to spawn a second shell ontop of the existing one (which can cause problems). See this relevant SO question.

NB2: on a fresh system the /view/some-view directory/-ies are not created by default. To create them you have to do the following:

cleartool setview some-view

By the way, once you execute ct setview you are placed in a new shell. You may exit that shell immediately if you like as you simply called ct setview for the side-effect of creating the view directory.

You obviously need to do the above only once. Once the /view/some-view directory gets created, it stays there.

NB3: you will notice that the ctmv alias above sets the group as well. As such, when one navigates directly to /view/view_tag_name/vobs/ASC_DB_ADMIN directory the group has to be properly set (with newgrp ccase) otherwise some common check-out / check-in commands won't work.