How can I improve performance on the Application of ClearCase Labels?

I often visit shops that complain of excessive label application times in their build process. For example Acme Company applies a label for each integration build which they do twice a day) and the application of the labels takes 2.5 hours for a build that itself only takes 1.5 hours (4 hours - ouch). Furthermore, they never keep the labeled build unless it is successful and passes a testing phase. In this case they spend 5 hours a day applying labels on a configuration that they rarely use.

When they challenged me with this problem, my initial response was why "apply" the labels until you know it is something you want to save, to which they responded "we won't know if we want it until much later so we have to label it when we build"... Well I beg to differ, I think we can eliminate the label application time (or at least defer it until we determine that we "like" the build).

Consider, that when you do a build the config. spec. is always known and you are usually are building on checked in code (or should be). So if the config. spec. is known and all code is checked in then you don't need to "apply" the label to reproduce the build configuration.

If you are in a view with a config. spec. like so:

   element * CHECKEDOUT   
element * /main/integration/LATEST   
element * REL1.0 -mkbranch integration   
element * /main/0 -mkbranch integration

and perform the build, you can always reproduce the "exact" configuration by using a config.spec. that is "time frozen" like the one below:

   element * /main/integration/LATEST -time 26-mar-2005.12:47:36   
   element * REL1.0 

So the key is to programmatically convert the config. spec. and save the config. spec. somewhere.
I usually choose to save it "in" the label definition. You can do this by saving the config. spec.
in the label "comment" or in some attached attribute.

Now when you create the "build" label you don't have to "apply" the label, just save the config.spec. that you will apply it to later if you like the build.

Create a script such that when you run it to make a new label type will also make a ""time frozen" config. spec. as the comment of the new label_type. This way the label itself does not have to be applied (in many shops taking hours) for each build. The associated config. spec. can be used instead to look at or build the "labeled" code. Then at any time in the future one can actually apply the label when the build is determined to be a "keeper" build.

For example:

   M:\coding\products> ccperl MAKE_BUILD_LABEL.pl BUILD_254

Creates the label type and produces a dialog like the one below:

Notice there is NO:

   element * CHECKEDOUT 
or    element * REL1.0 -mkbranch integration
or    element * /main/0 -mkbranch integration

I assume in an official integration build you do not checkout or want to select any checkouts.. but modify to your needs..

So now from a developer standpoint it is no harder really. Instead of setting the config. spec. rules to:

   element *  BUILD_256 they can set their config. spec. rules to the "comment" of the label BUILD_256 at anytime like so.    cleartool desc -fmt %c lbtype:BUILD_256 > temp_cs    cleartool setcs temp_cs   That label can actually be applied when you really determine you want to keep it via the normal
mklabel command like so:

   cleartool mklabel -rec BUILD_256 . 

Hope this helps... It is easy once you know how.