info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Branching bug ??? (was Re: Bug is tagging the head of a branchhead??


From: Paul Sander
Subject: RE: Branching bug ??? (was Re: Bug is tagging the head of a branchhead???)
Date: Wed, 19 May 2004 17:45:11 -0700

ClearCase is capable of supporting a number of branching models.  If you
read the ClearCase documentation, it never mentions a branch tree deeper
than 2 levels (including /main), so it's unclear what they really recommend
without taking an advanced class or hiring consultants.  And even then you
might get different recommendations from different parties.  If you have an
existing model then consultants would probably recommend using it in the
name of maximal knowledge transfer on the part of the users.

That said, using a config spec similar to the following implements the
behavior that Chris describes:

element * CHECKEDOUT
element * .../branch2/LATEST
element * .../branch1/LATEST -mkbranch branch2
element * .../main/LATEST -mkbranch branch1

Or the following might be used if branch sprout points are labelled:

element * CHECKEDOUT
element * .../branch2/LATEST
element * .../branch1/BRANCH2 -mkbranch branch2
element * .../branch1/0 -mkbranch branch2
element * /main/BRANCH1 -mkbranch branch1
element * /main/0 -mkbranch branch1

This is a time-honored and common branch methodology in which the
actual branch tree shown in a file's version history matches the
logical structure, assuming that versions have been created on
every branch.

The benefit to this is that it's easier for the users the wrap their
minds around branching because any given branch appears in the same
place in the branch tree.  That's not the case with lazy branching,
which is why process reviews done by developers often favor this method.

BTW, the amount of merging is the same between this method and lazy
branching.

Going off on a tangent, it's possible to reduce any branch tree to maximum
depth of 2 (trunk plus one level of branching).  The method involves
sprouting the new branch from the same point as the parent branch, then
copying the actual sprout point from the parent to the new branch and
checking it in as the first version on the new branch.  The benefit to this
is that branch trees are easy to render and understand.  The drawback is
the overhead in branch creation.  Merge efforts are also different due
to the change in the common ancestor computations, but it's hard to know
if the change is detrimental or not.

--- Forwarded mail from address@hidden

I'm confused, My understanding is that Rational( or IBM ) recommends a
sparse branching methodology.  This methodology is the same one used in
cvs.  So the question becomes how are you doing your branching in
clearcase, and what do you consider it's benefits over this methodology?
I'm at a loss currently to explain why I'd want to create /0 versions
before I needed to on a branch( it forces merges that don't have to
happen ).

--- End of forwarded message from address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]