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

[Donald Sharp \(sharpd\)]

I don't deny that clearcase is capable of supporting a number of
branching models :)..  What I was saying is that forcing a /0 version on
parent branches can and will cause unnecessary merges( perhaps trivial,
but it's more work still, even more work in cvs for that matter ).
Especially if you are performing syncs on a regular basis between
branches, and long lived development is going on in child branches from
the original child branch.

Looking at the examples in the 'ct man config_spec' I see multiple
examples of more than 2 levels of branching.

And I've read white papers from rational that describe the sparse
branching methodology as the one to go with( unfortunately it was years
ago and I can't find the link this morning :) ).  As I recall they
recommend this methodology because it creates far far fewer versions of
elements, and back in the schema 53 days this *actually* mattered to a
very large extent.  Also anything that you can do to reduce the size of
the vob is important.  Performance can be a real dog on heavily
branched/versioned files( there's some n2( or worse ) algorithms tucked
away nicely in the internals, I would imagine ).  Anything that you can
do to avoid it is highly important, in my opinion :)

donald

-----Original Message-----
From: Paul Sander [mailto:address@hidden 
Sent: Wednesday, May 19, 2004 8:45 PM
To: address@hidden; address@hidden;
address@hidden; address@hidden
Subject: RE: Branching bug ??? (was Re: Bug is tagging the head of a
branchhead???)


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