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:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 8:45 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
