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
