I have labelled a file "Test.java" with a label called "My_Label".
When I try creating a view with the below config specs, I am unable to get the file in Clearcase Explorer.
element * CHECKEDOUT
element * My_Label
Could anyone please tell where am I going wrong in the above config spec?
That selection rule alone isn't enough.
You need to add, before that rule, other rules that will select the right version of the parent directories.
In other words, if your parent directory (or one of the ancestors) of Test.java isn't labelled with My_Label, it won't be selected at all.
So your file won't be accessible by your view, even though you have the correct selection rule for you file.
Check if the Vob itself has been labelled with MyLabel.
If not, I would recommend at least to add one final "stop" rule (/main/LATEST: see "ClearCase Branching using configspec" for an illustration of that rule):
element * CHECKEDOUT
element * My_Label
element * /main/LATEST
Related
The team would like to perform their work with one webview (instead of a view for each vob). vob1 work should be done on main, whereas vob2 work should be done on a different branch (branch1 below). I am not sure what the conceptual problem is with my rules below. I expected that since clearcase will match rules from top to bottom it would apply the selections for vob1 I have specified.
The config Spec I tried will checkout files for vob1 on branch1 instead of main.
element * CHECKEDOUT
element /vobs/vob1/* .../main/LATEST
element /vobs/vob1/* /main/LATEST
element * .../branch1/LATEST
element * /main/LATEST -mkbranch branch1
element * /main/0 -mkbranch branch1
load /vobs/vob1
load /vobs/vob2
Is my desired goal possible? What is the error above?
First, don't hesitate to make a dynamic view in order to test your selection rules: you will see immediately if said selection matches what you need, without having to re-update your snapshot view.
Second, try element /vobs/vob1/... instead of /vobs/vob1/*: that will include the vob root folder itself.
See "Pattern" in the page "config_spec".
How do I checkout different branches of the same element in the same view by modifying the config_spec accrodingly in Clearcase?
Clearexplorer is giving message that already another version is checkedout in the same view, even though I have selected another branch in the config_spec rule correctly.
Any clue will help me.
Thank you.
Hello,
I added the VERSION TREE Picture where it shows that another CHECKEDOUT element is UNRESERVED mode. So, checkout on another branch of the same element in the same dynamic view fails with the message that another element version is already checkedout.
Error Message is also attached by creating another UNRESERVED CHECKOUT as shown.
The view is set to select only one version at a time.
If you want to checkout in another branch using the same view, you would always get the error message stating that the file is already checked out in the current view.
You can try change the config spec in order to:
select a non-checked out version of the file
make sure the checkout will create a new branch
But even in that case, ClearCase might refuse to check out twice that file in the same view.
Don't forget the selection rules in the config spec are read from top to bottom: the first one which can be applied applies.
So when you say "I have selected another branch in the config_spec rule correct", make sure that rule is in the top.
But I don't believe the error message will be different.
That issue is different from "How to Checkout (reserved) an element that is already checked out (reserved) in another view", where the solution is simply to checkout unreserved.
As your screenshot shows (from the position of the "eye"), your config spec select:
checked out version first
/main/LATEST
You would need to put a selection rule at the top of your config spec in order to:
select LATEST of app_build_changes
That is:
element * .../app_build_changes/LATEST
element * /main/LATEST -mkbranch app_build_changes
element /main/0 -mkbranch app_build_changes
But since:
the very first rule would still be element * CHECKEDOUT
you already have a CHECKEDOUT version
Your other rules would still be ignored, and the eye would still select the version you show in the first screenshot.
In short: use another dynamic view.
Instead of using
element * CHECKEDOUT rule in the config_spec,
if I change it to
element * /main/CHECKEDOUT -- one time when I am in main trunk
element * /main/app_build_changes/CHECKEDOUT -- another time when I am in branch
Then also it doesn't check out and gives me the same error of duplicate checkout in the same view.
I wanted to create a dynamic view with the following config spec:
element * CHECKEDOUT
element * .../view_1_1/LATEST
element * LABEL_1 -mkbranch view_1_1
element * /main/LATEST -mkbranch view_1_1
Unfortunately I have written the config spec wrong; I didn't write the "..." in the second line (element * /view_1_1/LATEST). After this, I have given the 'mkbrtype -global -c "some comment" view_1_1' command and make it visible in Windows (ClearCase Explorer) using Region Synchronizer.
And I realized that I have forgotten '...', so I corrected the config spec. I corrected this before any checkouts, checkins or something.
Does this edit cause any problems, or any differences than other views created with the correct config specs?
Does this edit cause any problems, or any differences than other views created with the correct config specs?
No, this edit is in the config spec of your view, and remains local to this view.
It has nothing to do with the fact the view tag was made visible through the Region Synchronizer.
The OP groove asks in the comments:
Is this true for editing config spec after "mkbrtype" too?
Yes: the brtype can change, the config spec will use that modified brtype at the next refresh.
The '...' is a simple selection rule modification, which means it will select different elements based on the new rule (.../view_1_1/LATEST instead of /view_1_1/LATEST or /main/view_1_1/LATEST).
If the brtype doesn't exist yet, or if its comment changes, that selection rule would simply be ignored.
config spec is read from the top to bottom by actived view. If the view finds one version of file/folder's tree, stop reading the next config spec.
In your case, when the view read second line element * /view_1_1/LATEST, since there is no branch /view_1_1, just ignore it, nothing happens, and continuously read the rest.
mkbrtype is used to define the properties and create branch type view_1_1 (not create the branch on that element). You need know command mkbrtype and mkbranch are different.
mkbranch
Creates a new branch in the version tree of an element
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_mkbranch.htm
mkbrtype
Creates/updates a branch type object
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_mkbrtype.htm
We usually use snapshot views and they work just fine.
However, I tried to use a dynamic view recently and doesn't show empty files in the working directory. We use Python so namely, it doesn't show empty __init__.py files, which breaks most of our code. All other files in the same directory, and non-empty __init__.py files exist.
Is this a known issue? What can I do?
Running cleartool ls says about the __init__py file: "no version selected".
My config spec looks something like this:
element * CHECKEDOUT
element * SubComponenet1_VersionX
element * SubComponenet2_VersionY
element * SubComponenet3_VersionZ
element /src_base /main/LATEST
Assuming the empty files are inside src_base and considering the last rule, how can a file not have a selected version?
First, try a cleartool ls in the parent directory of those file, in a shell or a DOS windows.
You can see there status, and see if they are selected by your config spec.
Check also that the config spec of your dynamic view is similar to your snapshot view:
cleartool catcs within your snapshot view
cleartool edcs from your dynamic view
For a non-UCM dynamic view to reflect an UCM snapshot view, it can be pretty complex.
It is best to create a dynamic UCM view on the same Stream.
At the very least, your config spec should end with a stop-rule:
element * /main/LATEST
# or
element /src_base/... /main/LATEST
Your last rule is only for /src_base directory, and not for the sub-elements.
My base ClearCase config spec reads like this:
element * CHECKEDOUT
element * .../Branch_F13R2/LATEST
All is good, but I am wondering what is the .../ doing at the beginning of the path? In UCM, we can see the streams and VOBS in Clear Case explorer, but in base ClearCase, how to know that if I want to check out from Branch_F13R2, I need .../ at the beginning?
That is because you don't know the parent branch.
.../ in a selection rule allows for ClearCase to select that branch, from whatever branch it comes from: /main, or any other branch.
To see more about that notation, called ellipsis wildcard, see "Find all files modified in a specific ClearCase branch?".
I would also recommend to add the rule
element * /main/LATEST
Not every parent directory has a version in the branch you are looking for, and without this last selection rule, it would have nothing to select, making any sub element inaccessible.