I am often asked questions like:
"Why does it take so long to apply a label to 30,000 elements." The short answer is "because you are applying a label to 30,000 elements".
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 . OK, now you want the script, that is the easy part because it is already written for you. There is
one in the ClearCase Trigger>Tools section of the forum named MAKE_BUILD_LABEL.pl. Hope this helps... It is easy once you know how.
Charles Clarke III is President of A Better Solution, Inc. With over 20 years of professional IT experience as both a software developer and CM Professional, he saw the need for a CM consulting company from his early experiences with Atria (the original makers of ClearCase). To this end he has assembled some of the best software minds in the country to bring the experiences of many minds in many development shops together to aid in the implementation of ClearCase. He was the software architect of some of the most successful ClearCase add-on tools, ClearTrigger, ClearReplica, ClearWeb and ClearManage. ABS provides consulting, tools and training to suit an organizations needs for ClearCase. Visit http://www.abs-consulting.com for more details.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed