ClearSCM: cc/etf.pl

NAME etf.pl

Evil Twin Finder

VERSION

Author: Andrew DeFaria <Andrew@ClearSCM.com>
Revision:: Revision 1.3
Created:: Fri Apr 23 09:40:31 PDT 2010
Modified:: Modifed 2010/06/05 02:55:03

SYNOPSIS

 Usage: eft.pl [-u|sage] [-ve|rbose] [-d|ebug] [-di|rectory <dir>]

 Where:

  -u|sage:       Displays usage
  -ve|rbose:     Be verbose
  -d|ebug:       Output debug messages

  -dir           Directory to process

DESCRIPTION

This script will search for existing evil twins in a Clearcase vob. It is intended to be used in the context of a base Clearcase view with a default config spec.

An evil twin is defined as two or more Clearcase elements that share the same path, and same name, but have different OIDs thus having different version histories. This can occur when a user creates an element in a directory that used to exist in this same directory on another branch or on a previous version of the same branch. By default Clearcase will create an element with a new OID. This new, evil twin will then develop it's own version history. This then becomes a problem when you attempt to merge branches - which twin (OID) should Clearcase keep track of?

Most Clearcase users implement an evil twin trigger to prevent the creation of evil twins but sometimes evil twins have already been created. This script helps identify these already existing evil twins.

Note: Evil twins can also happen if you only apply your evil twin trigger to the mkelem Clearcase action. It should be applied to the lnname action as elements come into creation by things like the cleartool ln, mv and mkdir commands. These all eventually do an lnname so that's where you should put your evil twin trigger.

ALGORITHM

 TODO: Is cleartool find really needed? I mean since we are going through
       the extended version namespace don't we by default find all
       subdirectories?
 
This script will use cleartool find to process all directory elements from
$startingDir (Default '.'). For each version of the directory a hash will be
built up containing all of the element names in that directory version.
Elements are always added and never deleted in this hash as we are looking for
all elements that have ever existed in the directory at any point in time.

This script then dives into the view extended namespace for directory elements examining the internal Clearcase structures. If we find a branch we recurse or numbered directory version we recurse looking for file elements (TODO: What about directory evil twins?). Note that we skip version 0 as version 0 is never interesting - it is always a duplicate of what it branched from and empty.

Directory versions that are not numbered are labels or baselines that point to numbered directory versions so we don't need to look at them again.

For each file element we find we use the cleartool dump command to get the OID of this particiular versioned element and build up an array of hashes of all the elements in the directory. For each element version we maintain a hash keyed by the OID. The structure also contains a count of the number of times the OID was found. An evil twin therefore will have multiple OIDs for the same element version name.

After the directory is processed we look though the array of hashes for elements that have multiple OIDs and report them. Then we proceed to the next directory.

ENVIRONMENT

If the environment variable VEBOSE or DEBUG are set then it is as if -verbose or -debug was specified.