1. view diff with the immediately previous version of a file
  2. One can use ct diff as in:

    ct diff -pre /path/to/file
    … personally I'd much rather use git diff and the virtual file system that's accessible after sufixing the file's name with @@.

  3. graphical tool to view commits / branches / merges on files
  4. 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

  5. how to see which version of a file gets picked up by the view I am currently in
  6. ct ls -l some/file
    … the above incantation also shows the rule that gets applied and selects this particular version.
  7. how to see the commit history of a particular file
  8. ct lshistory some/file
    … the above command reports latest commits first (higher up in the output). Dates are displayed in the US notation without the year. To see the year as well, do:
    ct lshistory -long some/file
  9. how to see all available views
  10. ct lsview
  11. how to examine the view configuration of a particular view
  12. 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):

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

    ct catcs
    … to see that view's configuration.

    NB: rules that appear first (higher up) in the ct catcs output take precedence over rules that appear further down.
  13. how to edit your view configuration to pickup a specific version of a specific file
  14. In my particular case, I had the file showcased in this tip where the latest version was /main/dbdev_br/5 (and was also laballed ANTBUILD). My original config spec was the following:
    $ ct catcs
    element * CHECKEDOUT
    element /vobs/ASC_BUILD/... ANTBUILD
    element src/db/... .../dbdev_br/LATEST
    element * /main/LATEST -mkbranch dbdev_br 
    … and was pointing at the /main/dbdev_br/5 version. To nail that file to the /main/dbdev_br/4 version I only had to add a single line (using ct edcs) as follows:
      $ 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
  15. how to list all versions and labels on a file
  16. Take advantage of the pseudo-filesystem that CC uses &emdash; accessible with the @@ symbols. Since the CC pseudo-filesystem is accessible like any normal filesystem, you can use typical programs such as tree or find. Example output:
    $ tree  /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
  17. how to list the current version of a file used by a view and the rule that applied
  18. 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 

  19. text_file_delta: Error: "some/file" is not a 'text file': it contains a line exceeding 8000 bytes.
  20. 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
    … once you do that you don't need to re-run mkelem as the element already exists:
    $ 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".
    … Instead, running ci is enough:
    $ ct ci -nc jquery-3.2.1.min.js
    Checked in "jquery-3.2.1.min.js" version "/main/dbdev_br/1".

  21. command to "start" a view
  22. Apparently the below is sometimes needed following a ClearCase restart:
    cleartool setview mperdike_dev_view
  23. create (and commit) a directory in ClearCase
  24.     ct co <parent directory>
        ct mkdir dirname
        ct ci <parent directory>
  25. commit an existing file or symlink in ClearCase
  26. 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"

  27. working directly on the filesystem in ClearCase (not inside an extra shell using setview)
  28. See the following SO question of mine:

    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).

  29. awesome tool to import an arbitrary directory structure into a ClearCase view
  30. 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:

    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/ .
    For more on the update functionality, see here.

    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.

  31. some useful commands I used recently (unordered)
  32. 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
  33. remove a file or directory (recursively) in ClearCase
  34. $ 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.

  35. find whether the current directory is checked out
  36. ct des . | grep check
    … or:
    ct lsco -dir .
  37. how to find view-private objects
  38. In the current directory only (non recursively):

    ct ls -l | grep private
    … alternatively:
    ct ls -view_only

    Recursively, under the current directory:

    ct lsprivate .
    … alternatively:
    ct ls -view_only -recurse

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

  39. remove a dir and all its sub-directories
  40. Say you wish to remove directory dir-to-remove in present directory.

    ct co -nc .
    ct rmname dir-to-remove
    ct ci .
    -nc stands for no comment

  41. how to delete a view in ClearCase
  42. I have only tried this with a snapshot view but I believe it works with dynamic views as well:
    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.

  43. how to create a snapshot view in ClearCase
  44. Here's the incantation I recently used:
    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
    Here's my understanding:

    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 
    … whereas the snapshot view config spec is:
    $ 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?).

  45. how to create a dynamic view in ClearCase
  46. 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
    Here's my understanding:
  47. common helpful aliases for ClearCase and on the /view/some-view directory
  48. 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
    … once you execute above, lo and behold, the /view/some-view directory appears.

    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.