27/9/2007

dotline dotlinedot dot linedot line linedotlinedot dotlinedotdot dot dotline dotlinedot linedotlinedot dotline dotdotdot dot line dotlinedot dotdot linelinedot linelinedot dot dotlinedot dotdotdot linedotline dotdot linedot linedotdot linelineline dotdotlinedot linedotdotdot dotlinedot linelineline linedotline dot linedot

Aren’t ClearCase triggers kind of broken???

Filed under: — Mikolaj at analog clock showing 10:17

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:

always-false trigger

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.
override always-false trigger

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?

One Response to “Aren’t ClearCase triggers kind of broken???”

  1. My impression is that everything is missed up in clearcase. The whole thing is so damm complex and a productivity dumper.

    If you use a simple repository system like cvs or subversion (the ones i know, call me ignorant), you can actually work without having to think all day about the repository.

    If you use clearcase you will remember (and damm) every 2 minutes that you are working on clearcase.

    It seems to me that ibm guys thought that software development was really easy and they made the rational monster.

Leave a Reply

Internet Explorer ≥ 5 , Netscape ≥ 6 , Mozilla ≥ 1.4, Opera ≥ 6
Mikolaj Swidzinski