Our idea is here to have the main branch to contain only stable baselined
versions. All system build and release will BE done form the main branch.
disk space - you will not get significant disk space, by removing the branches
and versions unless the number of versions under each branch for the element are
very high and also it depends on the element type (storage type).
Number of branch types limits - I am not sure if there is any limit on the
branches, we have successfully used around 120 branches on a single vob.
Removing the branch will not free up space.
performance - yes there is a overhead, usually when the view is started,
refreshed, merging.
The idea of keeping the branches intact is to have the history this is because
each developer does local testing (unit test), local builds, etc. before sending
for merge.
If you happen to ensure all required versions from the developers branch is
merged on the main branch and your sure the intermediate version on the
developers branches are not required (not have significant changes) then it is
all right to remove the developers branch.
- ensure identical checkin are disallowed
- you may treat group of people as unit and have one branch for the unit
- Also if you need to remove only the instance of a branch then use chtype.
-- 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
Burdin Nicolas wrote:
> 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