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, IndiaTel: +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 > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > > > > > > > > http://clearcase.rational.com/cciug/mailing_list.html > > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > > > > > 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