Christian,
I abstracted for simplicity of explanation, but I'm sure... in that it must
evaluate the rule in order such that in order for it to match the Xth rule
it must have evaluated and failed to match on the X-1 rules for each
element to be selected. Not to fully suggest thought the exact method to
determine if the rule matches though.... that is where the abstraction
is.. I won't profess to know the code determines match for a particular rule.
-Charles
At 07:35 PM 2/9/00 +0000, you wrote:
>Are you sure that this analysis is correct? It would be nice to hear from
>a developer who's actually seen the code. I can imagine a way of doing
>this in such a way that the performance impact is just a simple hash
>lookup.
>
>Not that I fundamentally disagree - element * is likely to be the fastest
>in all cases.
>
>I guess that if your process uses labels heavily, a decision needs to be
>made whether attaching labels to all elements and using element * is
>better or worse than attaching labels to only a subtree and using many
>element rules. Imagine some mega-source tree with a million elements in a
>thousand vobs, where labeling all of them may take days...
>
>My choice in such an environment would be to dispense with labels
>alltogether and use -time rules to create "virtual" labels in conjunction
>with project specific release branches. Then it's just a matter of using
>the correct search list for findmerge and recording the time when it's
>being done.
>--
>cg
>
>
>On Wed, 9 Feb 2000, A Better Solution, Inc. wrote:
>
> >
> > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > >
> > > > > can also
> unsubscribe
> > > > >
> > > > > 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 |
> > >======================================================================
> > >
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
> >
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:08 EDT