Assuming you are using a config spec of the kind:
element * CHECKEDOUT
element * .../development_branch/LATEST
element * /main/LATEST -mkbranch development_branch
(possibly adorned with branch point labels or a -time rule)
Add this to your findmerge query:
-element 'brtype(development_branch)'
This will restrict the search to elements that have actually have a chance
of being modified, ignoring those that don't even have a branch. This will
_immensely_ speed up your merges (in my case it was 20min -> 20 sec on
average).
Also, make sure your developers use new development branches once in a
while, so that the number of elements that have a branch stays small.
-- cgOn Thu, 10 Feb 2000, Burdin Nicolas wrote:
> > Hello, > > In our team, we use one branch by development (so at least one by > developer). We use merge to the branch main to delivery the SW, and some > labels to reference the global state. Everything is perfect. > But, recently, someone said to me that they had a lot of problems with this > way of works (because of the merge, big lack of performances...). Someone > from Rational had come to see the problem and had advised against the merge > and the usage of the branch ! > I'm not sure, but during these problems, the release of Clearcase was V2. > > 1 - Could it explain these problems and this advice of Rational ? > > 2 - Does anybody have the same problems with V3 (or V4) ? > > All your opinions are welcome. > > Best Regards > > Nicolas Burdin <burdinn@thmulti.com> > Thomson Multimedia > France > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > http://clearcase.rational.com/cciug/mailing_list.html >
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:11 EDT