{"id":63,"date":"2012-09-08T22:10:35","date_gmt":"2012-09-08T22:10:35","guid":{"rendered":"http:\/\/elene.dahners.com\/blog\/?p=63"},"modified":"2013-02-08T08:22:37","modified_gmt":"2013-02-08T13:22:37","slug":"clearcase-useful-tidbits-from-work","status":"publish","type":"post","link":"http:\/\/elene.dahners.com\/blog\/2012\/09\/08\/clearcase-useful-tidbits-from-work\/","title":{"rendered":"ClearCase: useful tidbits from work"},"content":{"rendered":"<p>Where I work, the primary version control system used is ClearCase. It&#8217;s the first version control system I learned, so even through its challenges, it remains my reference point for learning other version control systems. It&#8217;s easy to become familiar with the basics, but I&#8217;ve learned a few tricks that I find myself having to re-look-up, hoping I can find them again because I don&#8217;t need them frequently. That and, a lot of the tasks we used to do manually, we have rolled into scripts which govern building tasks so less is left to human error. So, here I will note some of the things I&#8217;ve found useful, but don&#8217;t always remember without looking them up.<br \/>\nTwo of my favorite references online are:<br \/>\n<a title=\"YoLinux\" href=\"http:\/\/www.yolinux.com\/TUTORIALS\/ClearcaseCommands.html\" target=\"_blank\">YoLinux<\/a><br \/>\n<a title=\"Phil for Humanity\" href=\"http:\/\/www.philforhumanity.com\/cat5.html\" target=\"_blank\">Phil for Humanity<\/a> (all the articles labeled &#8220;ClearCase Support&#8221;)<br \/>\nThen you have the regular, old manual:<br \/>\n<a title=\"IBM Cleartool Manual\" href=\"http:\/\/publib.boulder.ibm.com\/infocenter\/cchelp\/v7r0m0\/topic\/com.ibm.rational.clearcase.cc_ref.doc\/topics\/ctintro.htm\" target=\"_blank\">IBM Cleartool Manual<\/a><\/p>\n<h1>cleartool ls<\/h1>\n<p>We&#8217;ll start with something obvious, that I don&#8217;t really have to look up, I just tend to have to think for a few seconds before I remember that it will help me figure out why I&#8217;m looking at the wrong thing. To clarify, if you&#8217;re in a directory, and you use <code>cleartool ls<\/code>, it will list the contents of the directory and which configuration specification rule is active on said item.<\/p>\n<h1>cleartool lsco<\/h1>\n<p>This, I found, was important for avoiding trouble when importing. <code>lsco<\/code> (or <code>lscheckout<\/code>), as may seem obvious, lists files checkedout. What was useful to me was checking on a specific branch, so I was using something like:<\/p>\n<pre>cleartool lsco -brtype BRANCH -recurse<\/pre>\n<p>Another useful checkout search is for all your own checkouts (via <code>-me<\/code>) in your view (current view via <code>-cview<\/code>), in all vobs (via <code>-avobs<\/code>)<\/p>\n<pre>cleartool lsco -me -avobs -cview<\/pre>\n<h1>Find a branch or label<\/h1>\n<p>Need to know what labels or branches exist?<\/p>\n<pre>cleartool lstype -kind brtype -invob \\my_vob<\/pre>\n<p>The <code>-invob<\/code> option can be super helpful if you are potentially in a different vob.<br \/>\nAlternatively, if you want to check if a single label or branch exists, another option is to ask for its description.<\/p>\n<pre>cleartool desc -s lbtype:MY_LABEL<\/pre>\n<h1>Importing<\/h1>\n<p>We regularly imported source from a vendor, which we added on to, so it was important to keep things organized. This was our standard import call.<\/p>\n<pre>clearfsimport -nsetevent -recurse -mklabel &lt;LABEL&gt; &lt;DIR_TO_IMPORT&gt; &lt;CC_LOCATION_TO_IMPORT_TO&gt; 1&gt; Logfileofyourchoice.txt 2&gt;Errorlogfileofyourchoice.txt<\/pre>\n<h1>Finding things<\/h1>\n<p>Just as an example, this will find all items on <code>my_branch<\/code> and as it finds each one, it will bring up a version tree for it. This can be useful in small cases, but is not advised when there will be many results.<\/p>\n<pre>cleartool find . -version \"version(...\/my_branch\/LATEST)\" -exe \"cleartool lsvt -g %CLEARCASE_PN%\"<\/pre>\n<p>(Note: the use of &#8220;.&#8221; is to indicate that the search should be in the current folder; you may replace this with a different path.)<br \/>\nOf course, alternatively, you can get just a list of all the files by replacing <code>-exe<\/code> and its parameters with simply <code>-print<\/code>. It can also be helpful sometimes to find files changed between two points, in which case, in the <code>-version<\/code> parameter block, adding <code>&amp;&amp; !version(...\/other_branch\/LATEST)<\/code> is helpful. Note that <code>-version<\/code> isn&#8217;t terribly picky, so you can use branches or labels in the ().<\/p>\n<h1>Doing something with what you find<\/h1>\n<p>In the previous example, the -exe told ClearCase to open the version tree for each file found. Another example is to label each file found:<\/p>\n<pre>cleartool find . -all -version \"lbtype(&lt;LABEL&gt;)\" -exe \"ct mklabel &lt;OTHER_LABEL&gt; %CLEARCASE_XPN%\"<\/pre>\n<p>Here we use the clearcase special variable (with the extended path name, which would be more important if we changed &#8220;.&#8221; to a different folder) to indicate the file we&#8217;d like to apply a secondary label to.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Where I work, the primary version control system used is ClearCase. It&#8217;s the first version control system I learned, so even through its challenges, it remains my reference point for learning other version control systems. It&#8217;s easy to become familiar &hellip; <a href=\"http:\/\/elene.dahners.com\/blog\/2012\/09\/08\/clearcase-useful-tidbits-from-work\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28,27],"tags":[43,30,25],"class_list":["post-63","post","type-post","status-publish","format-standard","hentry","category-clearcase","category-version-control","tag-clearcase","tag-cleartool","tag-tips"],"_links":{"self":[{"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/posts\/63","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/comments?post=63"}],"version-history":[{"count":25,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/posts\/63\/revisions"}],"predecessor-version":[{"id":200,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/posts\/63\/revisions\/200"}],"wp:attachment":[{"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/media?parent=63"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/categories?post=63"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/elene.dahners.com\/blog\/wp-json\/wp\/v2\/tags?post=63"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}