I’ve been struggling to install the beast that is Clearcase 7.1.1 on a proof of concept server.
In this case the server is a Solaris 10 64bit install running on VMware Fusion 3.
One of the initial mistakes I made was to try and run the installation from a network mount. DON’T. Solaris must block the execution of code on some types of removable drives, which in this case was a VMWare Fusion shared folder.
A second thing that is not clear in the README files: Clearcase 7.1.1 on Solaris x86 does NOT support the GUI installation. Therefore, for me as much as any readers of this blog, I’ll document the steps to kick off a fresh/silent installation.
The install will be/have:
- A local install
- Clearcase Atria Licencing, local
- IBM Installation Manager installed first
- ClearCase installed second
- Download your entitled product for Solaris X86, for CC7.1.1 which is:
- CZ9XKML
- IBM Rational ClearCase V7.1.1 Solaris x86 Platform Edition Multilingual
If you need an evaluation copy, they are also available.
- Copy the archive to your server, and extract it. I’ll use /var/ccinstall for my install source, but adjust as required:
mkdir -p /var/ccinstall
cp -p CZ9XKML.zip /var/ccinstall
cd /var/ccinstall
unzip CZ9XKML.zip
cd disk1
- Follow the IBM documented steps for preparing a silent install. For my steps the dir /var/ccinstall/disk1 will be esd_image_root.
- Kick off the install:
/var/ccinstall/disk1/InstallerImage_*/install \
--launcher.ini \
/var/ccinstall/disk1/InstallerImage_*/silent-install.ini \
-silent \
-input clearcase_response_sol_x86.xml \
-log silentinstall.log
If you want to also show the progress, include the switch -showVerboseProgress
At this point kick back and make a few coffees.
Enjoy.
I previously showed you how to use a shell script with Rational Clearcase, to alert you when a new branch type was created.
In this post, I will show you how to use a Perl script to enforce Clearcase labeling conventions.
This example is directed toward Clearcase on UNIX (i.e. Solaris or similar) and assumes you have Perl installed, working and have a basic knowledge of how to program in Perl. It is a reworked version of the windows script supplied by IBM on Developerworks.
This is a long post, but a good one if you are a new clearcase admin who needs to enforce label names.
Read the rest of this entry »
I was looking for a simple way to have someone emailed when an event occurred in Rational Clearcase, like a new branch type being created. If you run Clearcase on UNIX (i.e. Solaris or similar) you can whip up a simple shell script and create your trigger. I will assume you have sendmail or similar already configured on your host so that mail utilities can send smtp mail
Lets have a go at it.
Write a shell script that uses mailx to send a message with some Clearcase trigger variables embedded in it, something like this:
Comma delimited email list of mail recipients
adminmail="youraddress@your.domain.com"
gets the host name
host=`uname -a |awk '{print $2}'`
send of message
echo "\
Creation of brtype \"$CLEARCASE_BRTYPE\"
by: $CLEARCASE_USER
comment: $CLEARCASE_COMMENT" \
| /usr/bin/mailx -s "[$host:CLEARCASE] New branchtype $CLEARCASE_BRTYPE created"
You can download this mail_new_brtype.sh if you are in a rush.
In this script you will see a number of variables starting with $CLEARCASE. These variables will be populated as environment variables when a trigger event occurs and launches the shell script.
The script should be saved somewhere it can be run on the UNIX server hosting the VOB, so when Clearcase triggers it can run the script. An appropriate location would be in the home directory of the VOB owner, for example:
/home/ccadmin/ccscripts/mail_new_brtype.sh
One you have saved the script, you need to actually make the trigger in Clearcase. Consider the following on creating this trigger type
- We need the trigger to run after the event, this is what is known as a “Post Operation”
- We want the trigger to be enacted after a new type is made, of type branchtype.
- We want the trigger to execute our shell script on the event occurring
You can research these options by viewing the man page of the command used to make a new trigger type:
cleartool man mktrtype
Once you have had a read of the man page, you should see some examples and options that can be used. Have a go at running the command yourself. This is what I came up with and should cover all our considerations:
cleartool mktrtype -c "Trigger to email cfgmgr on new brtype creation" -type -postop mktype -brtype -all -exec /home/ccadmin/ccscripts/mail_new_brtype.sh new_branch_trigger
My example shown here is relevant to Clearcase V6, so YMMV.
Once that has been run, you can see your new trigger listed in the trigger type list:
cleartool lstype -kind trtype
18-Dec.10:27 ccadmin trigger type "new_branch_trigger"
"Trigger to email cfgmgr on new brtype creation"
Next time a user creates a branch type, you will receive an email with the branch type name, branch type comment and whom created it!
Look for more upcoming tips; including how to make a trigger use a perl script to validate label names.
October 20, 2007 at 11:15 · Filed under clearcase
I’m coming to appreciate IBM’s Rational Clearcase, aside from the price point of course. But work have a license for it, and I have to use it. Don’t get me wrong, CVS is fantastic for tracking your small projects or larger ones with average complexity. I still use CVS for my own code, BUT clearcase has these features built in that you just start to take for granted. Here is a list of the ones I think make it a cut above CVS on a time intensive and complex project:
- Editing commit comments from the GUI or cmd line
- Triggers – including haveing pre and post operation triggers – some of mine are in perl!
- Labels vs CVS tags
- Element based branching based upon a view configspec
- Clear Merge Manager – This one is a lifesaver!
- renaming elements, specifically directories from GUI or cmd line
You can see from my short list that there are some things there that are powerful and make life very easy in a multi stream multi branch project management environment.
A case in point: I spent the last 3 hours baselining our Development, and testing branches – being 3 branches. We have started a new release cycle after our product has gone live in production, but there are still release fixes and defects being resolved that will get applied to production at a later date (2nd drop).
By baselining and labelling my code in these branches, I can easily track code changes across both the new development cycles and the concurrent release fixes.
On the whole, after half a year using Rational Clearcase, I can say the experience – despite the initial VERY LARGE learning curve – has been positive.