开发者

How to find a Parent Label of a branch in Clearcase

开发者 https://www.devze.com 2022-12-21 23:44 出处:网络
I have a view created for a child branch. For a given child branch name,开发者_JAVA百科 is it possible to find out the parent branch and the base label from which the child branch was created?A branch

I have a view created for a child branch. For a given child branch name,开发者_JAVA百科 is it possible to find out the parent branch and the base label from which the child branch was created?


A branch can be created from any version present in that view, as specified by the config spec.
The starting point can be a label, or a version reference by other criteria (date, LATEST from another branch and so on)

In short: you cannot; ClearCase is file-based, not repository-based.
That means you can decide starting a branch from different criteria, for each file selected by a given view.

Now, if you have one file already modified within your view (i.e. which has the new branch), you can:

 cleartool descr -l myFile

which should give you the extended pathname of the file:

 myFile@@/main/parentBranch/myBranch

the name of the branch before the new current one is what you are looking for.
You can determine that for a given file.


There isn't an easy answer to your question since the concepts do not necessarily apply. That means the answer must delve into the background too.

The config spec is the key to understanding how things will currently work (catcs). Looking at the actual file version names and version history (describe, lshistory) is the rest of the key to understanding how things were working at the time when a branch or version was created.

A branch exists independently of the files on it. For different files, the same branch name may appear at different places in the branching structure. A branch is not necessarily created from a labelled version of a file (though it sometimes is). Similarly, labels exist independently of the files that are labelled.

For example, consider a file I'm supposed to be reviewing at the moment (names disguised, but representative):

  • xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/TEMP.newfeat.it3/3

By delving into the history, I can see that the TEMP.newfeat.it1 branch was created from version xyzscan.c@@/main/89; this was not a labelled version because the previous fix pack used xyzscan.c@@/main/88 (labelled product-6.54.03, amongst others; the file had not been changed for several releases, let alone fix packs). The /89 version was a (minor) bug fix since the previous labelled version.

There have been 3 iterations of this particular new feature. The current config spec looks a bit like:

element * CHECKEDOUT

element * .../TEMP.newfeat.it3/LATEST
mkbranch TEMP.newfeat.it3 -override

element * .../TEMP.newfeat.it2/LATEST
mkbranch TEMP.newfeat.it2 -override  # Redundant

element * .../TEMP.newfeat.it1/LATEST
mkbranch TEMP.newfeat.it1 -override  # Redundant

element /vobs/product/...    /main/LATEST
include /atria_release/cspecs/otherprod/2.34/otherprod-2.34.05
element * /main/LATEST

The second and third 'mkbranch' lines are redundant now, but were relevant when their branch was the latest.

There are no labels on TEMP.* branches under our scheme (and ordinary engineers are not allowed to create branches that do not start "TEMP."; this is enforced by trigger scripts).

The xyzscan.c file was modified in each iteration. Using 'describe', I can see that:

  • xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/TEMP.newfeat.it3/0 was branched from xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/2

  • xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/0 was branched from xyzscan.c@@/main/TEMP.newfeat.it1/7.

But if I look at another file:

  • xyzread.c@@/main//TEMP.newfeat.it3/1

I can see that this was not modified until iteration 3 - there is no branch TEMP.newfeat.it1 or TEMP.newfeat.it2 for this file. Further, that is not a problem.


The question asks:

I have a view created for a child branch. For a given the child branch name, is it possible to find out the parent branch and the base-label from which the child branch was created.

Given a file in the view, you can run 'cleartool describe', possibly with the '-s' (short) option, to get its version number. In my example, that might be:

  • xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/TEMP.newfeat.it3/3

To find out where it was branched from, you need to look at the '/0' version on the branch, which is identical in content to the version on branch TEMP.newfeat.it2 from which it was branched. You need to then look at the full description of the '/0' version to see what the predecessor version was ('-s' is no help now). That was how I found that the predecessor version was:

  • xyzscan.c@@/main/TEMP.newfeat.it1/TEMP.newfeat.it2/2

Repeat going backwards. You can see labels that apply to version from which TEMP.newfeat.it3 was branched off in the (full) output from 'describe'. However, those labels may have been applied since the branch was created.

In general (though not in the example), there could be later versions on a branch such as TEMP.newfeat.it2 after the version where TEMP.newfeat.it3 was branched off. That always leads to questions of whether the extra changes on the TEMP.newfeat.it2 branch need to be merged down to the TEMP.newfeat.it3 branch - fortunately, ClearCase is pretty good about merges and merge tracking.


What branch, label or version your child branch will be based on is determined by the config_spec. Try to run cleartool catcs -tag <your_view_name> | grep -2 <your_child_branch_name>, that should give a couple lines before and after to give you the context. How the config_spec looks like varies wildly[1], so I cannot say if just greping for will be enough.

If you want to learn and understand you probably want to examine the whole config_spec. Within your view you can run cleartool ls [file(s)], the Rule: ... part will refer back to what within the config_spec that was applied.

[1] When I started using clearcase 12 years ago we just edited a few lines by hand, today it is generated by a tool and is hundreds (or thousands?) of lines.

0

精彩评论

暂无评论...
验证码 换一张
取 消