Darren,
Has the opposite effect... When you use the path name to match the
ClearCase has to compare /a/b/c to you element name before trying to match
on the label... when you use * then id does not have to try to match by
all on name since * matches everything.
consider the config spec.
element /a/b/c/f1 LABEL
element /a/b/c/f2 LABEL
element /a/b/c/f3 LABEL
element /a/b/c/f4 LABEL
and you cd to /a/b/c
CC now quickly finds the version of the f1 file by matching the first rule
CC finds the version of the f2 file by evaluating the first rule and
matching the second
...
CC finds the version of the f4 file by evaluating first 3 rules and
matching the fourth...
(in total 1+2+3+4=10 rules were evaluated)
NOW consider the 1 line config spec..
element * LABEL
CC finds all element with the first rule (only rule in this case)
for a total of 4 rules evaluated...
Hope this helps
-Charles
--- VOB Corleone
"One day.. and this day may never come... I might ask you for a favor.."
A Better Solution, Inc.
----------------------------------------------------
Charles Clarke III ClearCase Consultant
A Better Solution, Inc. (770) 252-1500 x22 [phone]
50 Springridge Ct.
Newnan, Ga. 30265 (770) 252-1501 [fax]
Email:
charles@abs-consulting.com
http://www.abs-consulting.com
At 06:37 PM 2/9/00 +0000, Darren Keverne wrote:
>Charles,
>
>
>Just out of interest, would using path names in the rules help to speed things
>up, like:
>
>element /a/b/c/... THIS_LABEL_HERE
>
>as opposed to:
>
>element * THIS_LABEL_HERE
>
>If the label is only on things below /a/b/c
>
>
>Regards,
>
>Darren
>
>
>"A Better Solution, Inc." wrote:
>
> > Srinivas,
> >
> > I could think of problems in performance...maintenance... etc.
> > consider the 1000 line config spec and the fact that they are evaluated
> > top down for every element to be displayed in a directory (or mercy the
> > build).. CC checks each rule from top to a match for each so every time you
> > step in to a directory it must evaluate the rules (in fact more often than
> > that- but lets keep is simple for now)... If you have 1000 lines that
> > means that some files use the 1000th rule (otherwise why have it).. now
> > lets say you cd to a directory where the "average" element in it matches on
> > one of the first 4 rules... you would see different performance than it you
> > cd in to a directory where the "average" element matched on the 1000th
> > rule... Imagine large directories that match on average the 1000th rule...
> > imagine complies... Such config specs effect compiles, directory
> > navigation, speed of GUI, speed of other tools... etc... NOT TO MENTION the
> > upkeep of such a file....
> >
> > Are you sure that you could not use another method.. labeling, branching..
> > etc..
> > How did and why are the config specs so verbose....
> >
> > -Charles
> >
> > At 10:01 AM 2/9/00 -0600, Srinivas Saraswatula (EUS) wrote:
> >
> > >Hi all:
> > >
> > >I am trying to find out if there is any limitation on the number of
> lines in
> > >a config spec.
> > >Are there any known problems caused by very large config specs (1000+
> > >lines)?
> > >
> > >Any info appreciated.
> > >
> > >Thanks
> > >
> > >Srinivas
> > >_________________________________________________________
> > >Srinivas Saraswatula
> > >ClearCase CM
> > >
> > >
> > >
> > >
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > >
> > >
> > >
> > > http://clearcase.rational.com/cciug/mailing_list.html
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
>
>--
>======================================================================
>| Darren L Keverne _ Email : dkeverne@ti.com |
>| CM Methodology _| '-. Mobile : dkeverne@bulletinmail.com |
>| ASIC Product Development \, _} MS : TIL/10 |
>| Texas Instruments UK \( Phone : +44 (1604) 663474 |
>| Northampton England Fax : +44 (1604) 663456 |
>======================================================================
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:08 EDT