Clearcase Config Spec with Private Branch

Question

I have a somewhat complicated branching structure at work (at least for me). It is something like this:

Main
 |
 1
 |
 2
 | \
 3   \
     Ver2
      |
      1
      | \
      2   \ 
      |   ProjectA
      3      |
             1

There are 2 branches off of main. "Ver2" which has everyone's changes for the next version, and "ProjectA" which is my work.

My question is: Is there a way to create a config spec that knows what has been merged so I get:

1. Anything from ProjectA that has not been merged
2. If the LATEST from ProjectA has been merged to Ver2, then get the LATEST from Ver2 branch
3. If there is not a ProjectA branch, get from Ver2
4. If there is no Ver2, get from MAIN

For example, in the above case, if I merged version 1 from ProjectA to version 2 in Ver2 branch, then I would want to see version 3 on Ver2. However, if I have not yet merged those files, I would want version 1 from ProjectA in my view.

Answer 1

I don't think you can do it quite like that. What you can get, though, is latest on ProjectA; anything on Ver2 that has not been changed in ProjectA; and anything on MAIN that has not been changed in Ver2 or ProjectA. The rest of the trick is ensuring that everything necessary has been merged from Ver2 or MAIN. For that, you can use a reference view with a config spec for Ver2 (you don't need one for MAIN unless Ver2 is not kept up to date), and then, in the ProjectA view, do:

cleartool findmerge . -fta view-tag-for-ver2 -merge

The -fta means "from tag". There are a myriad extra options, of course.

This ensures that ProjectA is fully up to date with respect to Ver2.

Answer 2

You have to remember why you define a branch:
To isolate a development effort.

So to better manage your complex config spec, you should know precisely what role play the 'main' branch, v2 branch and project A branch.

V2 and project A, for instance, should be there for two different reasons.

If Project A is there to develop the current version of the project, merges to V2 branch should occur to allow for retrofitting some of the current developments to the V2 branch.

By that reasoning, you should not want to see "both" in a same view: they represent two different set of files, V2 could include large refactorings with very different API.

However, should you insist on such a configuration, you could use the ability of moving a "MERGE_FROM_PA" label: each time you merge some files from Project A to V2 branch, you set again the "MERGE_FROM_PA" label for each merged file/directory, moving that label from previous V2 versions to their latest.

The config spec could be:

element * MERGE_FROM_PA
element * .../ProjectA/LATEST
element * .../V2/LATEST
element * /main/LATEST

But then again, that would not make much sense.

You need to define the different development efforts you want to modelize, and then define a coherent workflow, allowing your config spec to focus only on one of those environments.

Answer 3

Why not? Not using a branch if it's been merged somewhere makes sense to me.

Here's the Config Spec:

element * {version(.../ProjectA/LATEST)&&!hltype(Merge,->)}
element * {version(.../Ver2/LATEST)&&!hltype(Merge,->)}
element * /main/LATEST

what makes this workflow incoherent, as long as you label it all before a build?