>- disk space,
>- number of branch types limits,
Unless your branches number in the millions...there shouldn't be a problem....
>- lack of performance of CC to choose the good versions (even with a small
>config spec) ?
You normally wouldn't want to have the config spec look for elements that are on
a branch that has been finished with...
so there will not be any performance hit....
Andy
Burdin Nicolas <BurdinN@thmulti.com> on 11/02/2000 09:50:27
To: "'pushparaj.mariappa@blr.pin.philips.com'"
<pushparaj.mariappa@blr.pin.philips.com>, Andrew
Mcdonagh/MAIN/MC1@MCMAIN
cc: Burdin Nicolas <BurdinN@thmulti.com>, "'Christian
Goetze'" <cg@digisle.net>, "'cciug@rational.com'"
<cciug@Rational.Com>
Subject: RE: [cciug] Big problems with merge between
branches
But if I do so, with manydevelopers, and lot of small merge, I will have a
lot of branch types !
At the end, do I risk problems like :
- disk space,
- number of branch types limits,
- lack of performance of CC to choose the good versions (even with a small
config spec) ?
> -----Original Message-----
> From: Pushparaj Mariappa [SMTP:pushparaj.mariappa@blr.pin.philips.com
> Sent: Friday, February 11, 2000 10:38
> To: Andrew.Mcdonagh@marconicomms.com
> Cc: Burdin Nicolas; 'Christian Goetze'; 'cciug@rational.com'
> Subject: Re: [cciug] Big problems with merge between branches
>
> I do Agree .. Should not delete the branch. If further development is
> going to
> take place on the same branch, then I suggest you rename the branch_<date&
> time
> stamp) and recreate the branch. This way you will have the branch and its
> version
> and history intact and also the developers need not change the config
> spec. The
> renaming and creation of the branch can post merge (checkin) trigger.
>
> Let me know ur view.
> --
> Warm regards,
> Pushparaj Mariappa
> Philips Software Centre
> #3, Sterling Square, Madras Bank Road,
> Bangalore - 560 001, India
>
> Tel: +91-80-2997411 - 19 Ext 3056/57
> Fax: +91-80-2997420
>
> Andrew.Mcdonagh@marconicomms.com wrote:
>
> > You remove the branches that have been merged?
> >
> > No....doing that will lose the history.....
> >
> > Simply 'obsolete' the branches...this has the effect of hiding them ..so
> that
> > you can see the wood for the trees...
> >
> > cleartool lock -obsolete -brtype <myBranch>
> >
> > Andy
> >
> > Burdin Nicolas <BurdinN@thmulti.com> on 11/02/2000 08:31:08
> >
> >
> >
> >
> >
> >
> >
> > To: "'Christian Goetze'" <cg@digisle.net>
> >
> > cc: "'cciug@rational.com'" <cciug@Rational.Com>(bcc:
> > Andrew Mcdonagh/MAIN/MC1)
> >
> >
> >
> > Subject: RE: [cciug] Big problems with merge between
> > branches
> >
> >
> > Thanks to your response.
> >
> > We already work like that. More I advise tor remove the branch after a
> merge
> > so we could easely see which files have changed betwwen two merges.
> >
> > My question was more to kwnow if anyone else had the same problem and/or
> > your reactions.
> >
> > Best regards
> >
> > > -----Original Message-----
> > > From: Christian Goetze [SMTP:cg@digisle.net
> > > Sent: Friday, February 11, 2000 02:43
> > > To: Burdin Nicolas
> > > Cc: 'cciug@rational.com'
> > > Subject: Re: [cciug] Big problems with merge between branches
> > >
> > >
> > > 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.
> > > --
> > > cg
> > >
> > > On 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
> > > >
> > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > >
> > > > can also
> unsubscribe
> > > >
> > > > http://clearcase.rational.com/cciug/mailing_list.html
> > > >
> > >
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > >
> > > can also
> unsubscribe
> > >
> > > http://clearcase.rational.com/cciug/mailing_list.html
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
> >
> > http://clearcase.rational.com/cciug/mailing_list.html
>
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:11 EDT