ClearCase triggers are supposed to force the users to follow the policy. They need to be laying at some tamper-proof location, so that nobody tries to short-circuit them. Right? Sort of…

A small exercise.

Let’s first make an unfriendly trigger.

print "Sorry, this trigger is always false!n";
exit 1;

We’ll make it a pre-checkout trigger.
Try it:

Works as expected.
Now, I can’t modify the trigger (tamper-proof, remember :-D), why not wrap around ccperl.exe? Sorry for not doing things elegantly, it’s just an example:

/*******************************************************************************
 *                                                                             *
 * This thing does almost nothing. If it's not called as a trigger it just     *
 * calls ccperl2.exe with the same arguments. If it's called as a trigger. it  *
 * returns true                                                                *
 *                                                                             *
 *******************************************************************************/

#include <process.h>
#include <string>
#include <stdlib.h>
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
{
    string perlcall("C:\Progra~1\Rational\ClearCase\bin\ccperl2.exe");

    // pass all arguments to the script
    for (int i = 1; i < argc; i++)
    {
        perlcall+=" ";

        // Put back quotes...
        if (string(argv[i]).find(" ",0))
            perlcall+="\""+string(argv[i])+"\"";
        else
            perlcall+=argv[i];
    }

    int retVal= system(perlcall.c_str());
    if (getenv("CLEARCASE_TRTYPE_KIND") != NULL)
    {
        cout << "Well, now it's always true!!!" << endl;
        return 0;
    }
    else
    {
        return retVal;
    }
}

Of course, I could just have it return 0 without executing the trigger, but then, the screenshot below would be less self-explanatory ;-). So now, let’s rename ccperl.exe to ccperl2.exe, and use our fabricated ccperl.exe instead. Let’s see how it works.

And that’s it.

Sure that’s just one more thing to remember - don’t give users the rights to modify ClearCase bin directory. But if triggers are supposed to force user to do something, why is there’s no checking, whether ccperl.exe is really ccperl.exe and not some kind of a lousy wrapper?

Now, what is it that antivirus programs are supposed to do? Scan for viruses…. Scan for viruses, you say? Read the following and reconsider that:

10. ISSUE:
File operations invoked on IBM’s ClearCase file
system (MVFS) might cause our AV filter driver
to leak memory. Our driver can see folder OPEN
requests but never the CLOSE requests.

RESOLUTION:
The AV filter driver has been updated to exclude
file operations of IBM’s MVFS file system from
scanning operations.

Due to an apparent problem scanning files, our driver was updated not to scan them?!!

Hello? HELLO? I’m wondering if you guys at McAfee are actually reading what you write.

Here’s a link to that embarassing confession: VirusScan Enterprise 8.0i Patch 15 Readme

There’s “Compare with previous version” in the ClearCase context menu. Useful. But how much more useful would it be to compare with an arbitrary version! Of course, one could always do it in the version tree, but it’s a bit time consuming, for files with a lot of versions; Entering a version extended path on the other hand, would be daunting.

Before looking at the ClearCase context menu, here are the scripts that will do the things for us.

1. Here’s one that shows a list of labels and compares with the one chosen:

@rem = ' This is a perl script for NT.
@echo off
@ccperl "%~f0" %1
@goto endofperl
@rem ';

require File::Temp;
use File::Temp qw/ :POSIX /;

# create the temp file
($fh, $file) = tmpnam();

END 
{
  # get rid of the temp file at the end.
  close $fh;
  unlink($file) or die "Couldn't unlink $file : $!";
}

# quote for spaces
$ARGV[0]='"'.$ARGV[0].'"' if ($ARGV[0]=~/\s/);

$labels=`cleartool lshist -fmt \"\%l\" $ARGV[0]`;
$labels=~s/\)\(/\,/g;
$labels=~s/(\(|\))//g;

@labellist=split /\,\s*/,$labels;
@labellist=sort @labellist;

foreach $label (@labellist)
{
  $label.=",";
}

print $fh "@labellist";

if (!system("clearprompt list -outfile $file -dfile $file -prompt \"Select label to compare with\""))
{
  seek($fh, 0, 0); 
  $chosenlabel=< $fh>;
  print $file;

  `cleardlg \/diffother $ARGV[0] $ARGV[0]\@\@\\$chosenlabel`;
}
__END__
:endofperl

Create a file, say, complabel.cmd and copy & paste or get it here

2. For an arbitrary version, we just need to take the version-extended path and compare it with the path without the version:

@rem = ' This is a perl script for NT.
@echo off
@ccperl "%~f0" %1
@goto endofperl
@rem ';

# quote for spaces
if ($ARGV[0]=~/\s/)
{
  $ARGV[0]=~s/(.*)\@\@/\"\1\"\@\@/;
}

$ARGV[0]=~/(.*)\@\@/;
`cleardlg \/diffother $1 $ARGV[0]`;

__END__
:endofperl

Create comp.cmd and copy & paste or get it here

I haven’t played much with them, so there may be some quirks with strange characters, et al.

Now that we have perl scripts, let’s modify the context menus. Open ClearCase Context Menu Editor (Programs>Rational Software>Rational Clearcase>Context Menu Editor). We’ll create two menu choices (just enter what’s below):

1. Compare with a Label

Of course, you need to enter your own path to the complabel.cmd.

Browse into Version Tree:

This “@@” does the magic - take a path in dynamic view, add @@ and now you can browse the version tree and all labels. Someone sent this hack to CM Crossroads, I’d happily attribute him/her, can’t find it now, though…

Now, we add the entries under dynamic view file “Checked In” and “Checked Out”, and arrange them nicely

And that’s it for the Context Menu Editor, our entries should now appear in the context menu:

Warning!!! Lame!!! To finish the comparison with an arbitrary version, we will need to add a proper command to the windows context menu. Now, I don’t have time to learn how to write Windows shell extensions, to make it all nice and smooth. So I did it in a crude way - I created a shortcut to comp.cmd and added it to my SendTo:

Now, if you want to compare with an arbitrary version of a file - in the dynamic view select Browse into Version Tree, and then in the tree select “compare with me”:

And that’s all folks.

Two months ago I put online my license viewer script. I had some time on my hands, so I got rid of the msie:download object, and instead of parsing xml using javascript myself, I wrote an xslt that transforms xml files to javascript tables. Look at a demo here, download it here, read more here.

Update 2007-11-6: As I have upgraded to ClearCase 7 I found that the $! variable I was checking, is getting set to “Bad file descriptor” regardless of success of the operation. Must be something with the perl version they are distributing with CC 7. I changed that condition, but if you want the old version with normal check, it’s here.

Looking at some old ClearCase logs, I found this beauty:

vobrpc_server.exe(9880)/vob/map: Error: Something not found in VOB database: "name_of_the_database"

Update: If you just want a solution, the scripts for 3-way merging from within ClearCase are here. It seems some people are too hasty and seriously overlook the fact that it’s there in section 4. (see the first comment for instance)

Here’s the deal:
Araxis is nice, ClearCase is nice, let’s double the niceness.

There’s some info on how to use Araxis Merge with ClearCase: [1] for comparing files. Nothing about merging in ClearCase, though… (Update: this very page is linked there, so the last sentence is not true anymore)

1. Wrapper
ClearCase has type managers defined here:

ClearCase-dir\lib\mgrs\map

See [2], there’s also a description of a less blunt way of using type managers. The contents of the map file are straightforward:

each line is:
type-manager clearcase-action called-application

eg.

text_file_delta xcompare ..\..\bin\cleardiffmrg.exe
text_file_delta xmerge ..\..\bin\cleardiffmrg.exe

calls cleardiffmrg.exe to do a visual merge/visual compare of a file of text_file_delta type. That’s the lines we’ll want to hack…

It would be handy to use perl to play around with different parameters, rather than parse them in c++. Since ClearCase seems to expect an exe file, we need to craft some exe wrapper. Here’s the VC++ source: wrapper.cpp it just calls the merge.pl script with the parameters that it got, and returns the value it gets from merge.pl script. Simple. (never thought that argv strips the quotes from quoted parameters…). Now we replace ..\..\bin\cleardiffmrg.exe with the path to wrapper.exe that we just crafted.

2. Basic script
I made the first version of script quite neutral:
`echo cleardiffmrg.exe @ARGV >> some_log_of_mine`
exit system("cleardiffmrg.exe @ARGV");

just to see what happens under the hood. The script isn’t so neutral BTW (never thought that argv strips the quotes from quoted parameters…)

3. And this happens under the hood:
Assuming we are merging a file called file :-)

in dynamic view* clearcase calls cleardiffmrg with these arguments**:
-base common-ancestor-version -out file.merge source-version file

when the merge is successful, cleardiffmrg creates the file.merge.
cleardiffmrg returns to clearcase.
The dialog that appears (saying that that the merge was successful or not) depends on the return value from cleardiffmrg. The merge arrows are drawn depending on the existence of the file.merge.

* snapshot view has basically the same set of arguments, but the arguments not available in the view, are paths in the vob database. since this is not quite readable, the -fname arguments provide the titles of the panes in merge window. This -fname thingy is not limited to only snapshot views, which makes it quite handy, one can for example do a diff between two views, and explicitly put proper information in the window pane titles like this:
cleartool diff -graph -options "-fname bla1 -fname bla2" file-in-view1 file-in-view2
** if file.merge exists, it uses file.merge.1, file.merge.2 and so on. Actually it is not important as long as the file is passed as a parameter.

4. Less basic script
Now that we know the parameters, we can call Araxis compare.exe. The script and wrapper are here, together with a setup script for XP. NOTE: If you happen to use the scripts and something breaks, that’s because you shouldn’t have used it in the first place ;-). Actually nobody has been complaining yet, and it’s got already almost 1500 downloads. So it seems fairly safe…

5. Reality check - ongoing
For now, reality sucks. I must be able to force the user to merge to the right version, and force him to resolve all the differences, before closing, and compare.exe doesn’t do that. Maybe this could be solved playing with compare.exe examples, but I don’t have much time on my hands, and I am not even able to convert the sample vc++ 7 project to vc++ 6. . Forget it, I have been too conditioned by using the ClearCase merge. That subsided quickly :-)

Update 2007-11-06: As Jamil Taylor mentioned, CC 7 has a misbehaving perl version. As a result, the checks I made for contents of $! were failing. $! was set to “Bad file descriptor” despite `reg …` being successful. So I made a cleaner version of the install script which now uses Win32::TieRegistry instead. The merge script itself hasn’t changed. Old version here.
Update 2007-2-22: There’s an Araxis Merge 2007 preview, which uses a different registry key. I added it to the setup script.
Update: People are complaining that things don’t work after installing the merge script. The script sets a system variable. So don’t expect that you will be able to install it when in merge manager/version tree/etc., as they were started in the old context, so no variable was set at the time.

[1] http://www.araxis.com/merge/scm_integration.html
[2] http://www.guiffy.com/GuiffyHelp/ClearCase.html

The other day I needed to log a couple of ClearCase® licenses. So I dusted my license viewer I wrote back in ‘02. And it worked!

I took a little time to write a couple of lines about it and clear some cobwebs off my web pages. And here it is.

I’m not 100% happy though. The behavior of <msie :download/> object must be dependent on some IE security settings, since it didn’t function the same way on two different computers. And I am too lazy to check why. So I cheated with the example, which doesn’t load any logs whatsoever. Instead I turned the logs into tables.

Update: I have revamped the viewer so it no longer uses the msie:download. See here
If you download it, you use it at your own risk!

Update 2007-11-6: As I have upgraded to ClearCase 7 I found that the $! variable I was checking, is getting set to “Bad file descriptor” regardless of success of the operation. Must be something with the perl version they are distributing with CC 7. I changed that condition, but if you want the old version with normal check, it’s here.