My question is somewhat inverse to this one: Does ClearCase provide a way to make configspec rules overridable by others (even if they occur later in the configspec)?
Suppose you are releasing module A and module B contained in directories 'files/of/module/A' and 'files/of/module/B', say. To make sure that A doesn't depend on files from B's directory, I would like to add a rule like
element files/of/module/B/ -none
to the configspec that determines the release of A (and vice versa for B), call them 'A.release' and 'B.release'. But if we now want to integrate A and B somewhere together, our configspec looks like
include A.release
include B.release
But this won't work since 'A.release' hides all of B's files.
Is there a way to make the -none rule overridable, something along the lines of -none (weak), as long as the other rules aren't 'weak', too?
One idea to test would be with included config spec files.
Specifically:
test if you can specify a relative path ../none.csp (which includes the element files/of/module/B/ -none selection rule)
test what happen where there is no ../none.csp in the parent folder oa view
That way, your config spec would be:
include A.release
include ../none.csp
include B.release
One snapshot view would be created where none.csp is, and the element files/of/module/B/ -none would apply.
One other snapshot view would be created where that file is not there, and the none rule would not apply.
If B does not have -none rules for A, you could reverse the lines as well. B-then-A...
Myself, I would either evaluate using UCM, or possibly separate the various configspec phases into separate files:
Module A
Module A -none rules
Module B
Module B -none rules
This way you could have a configspec that runs like this:
include /net/server1/export/cfgspecs/modulea.config
include /net/server1/export/cfgspecs/moduleb-none.config
And later use:
include /net/server1/export/cfgspecs/modulea.config
include /net/server1/export/cfgspecs/moduleb.config
Related
Is it possible to know what line in a config spec applies to a specific element? Here is what I mean exactly:
If I do ct ls some_file, the output is going to be:
/path/to/some_file##/main/10 Rule: /main/LATEST -time 12-Jun-2013.18:00UTC+1
This is all fine and dandy, but I would like to know where exactly the rule comes from. Our company uses hierarchical config specs (config specs that include other config specs) so the rule might not be defined in the top level one.
Is there a ClearCase command that can show me in what file (and preferably also the line) the rule was defined?
Not that I know of.
But a config spec rule is applied from top to bottom, with the first one selecting anything being applied.
So in your case, you can go from the top config spec to the most specific one and the first one with a selection rule involving /main/LATEST wins.
See "How a config spec works"
To automate that process would mean:
take all config specs involved
build a config spec with the first line of the first config spec
check if that select your version with the same selection rule
if not, add the second line of the first config spec (and so on)
I'd like to have a ClearCase config spec that has this:
element /path/dut.csp /main/RELEASE_42
include /path/dut.csp
The problem I am encountering is that the include statement will include the version of the dut.csp file that is visible in the view before this config spec was set. It does not take into account the element rule the line before.
Sure I can call cleartool setcs -current, but what if this sort of approach is used again in the included csp file? How many times do I have to do this before the view is stable?
At the moment I am specifying ##/main/RELEASE_42 on the include statement as well. But then I have to edit both lines when I change the version. Also, if I want to checkout the csp file for development I then also have to edit my config spec to use the checked-out version.
Is it possible to use the include statement without a revision specification and have the earlier rules in the config spec evaluated before the include statement?
I am using ClearCase version 8.0.0.7.
No, it doesn't seem possible, considering the way selection rules are evaluated in a config spec.
That means you need to use:
a dedicated view to select the right version of that file
another view to use that include referring the file of the first 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
I have created a symbolic link for folder1 to make it available in vob2\rootdir from vob1\rootdir.
And I labeled the whole directory folder1 recursively in vob1.
But when I modified the configspec of dynamic view to load folder1, it was loaded under vob1; But I couldn't see that folder in vob2\rootdir. Pls help.
First you don't modify a config spec to load anything in a dynamic view: you only modify selection rules, there is no load rules (as opposed to snapshot view).
If you were actually using a snapshot view (with a path different from M:\ or /views), then beware of symlink resolution issue like this one.
Finally, if your config spec doesn't select vob2/rootdir, or if it doesn't select the version which recorded the symlink, you wouldn't be able to see said symlink.
That means, labelling vob1/folder1 isn't enough: you need to make sure that:
/vob2 is labelled
/vobs2/rootdir is labelled as well
In other words, the parent folders of your final selection target (target being '/vobs/rootdir/folder1) must be selected.
Good morning,
is there any way to exclude only one particular directory from a snapshot's load statement, e.g. I want to load a whole vob named 'PM_CT' except the \PM_CT\lost+found directory
... is there an elegant way to do it? And how would I generally exclude all lost+found directories across multiple loaded vobs?
Cheers and Thanks,
-Jörg
I would like to make an addition to the previously posted answer:
The lost+found directories
To exclude the lost+found directories across all VOBs you can modify the previously proposed selection rule to be more generic:
#Skip the lost+found directories
element .../lost+found -none
However, using the '-none' flag causes the Windows ClearCase client to list errors when updating a snapshot view:
Unable to load "lost+found": no version selected in configuration specification.
Unable to load "lost+found".
It also does not properly unload any previously loaded folders or files, so you may need to recreate your snapshot view (or unload/reload the VOB) with the new selection rule if you really want to clean out the lost+found directories...
Elegance
For excluding any normal folder, the "elegant way" would be to specifically load the /main/0 version of the folder:
#Exclude the contents of a directory
element /VOB_name/folder_path /main/0
This will cause the folder to be loaded as empty and will not produce an error. It will also properly unload any loaded files. It unfortunately does not work for the lost+found directory, because it is always listed as version /main/0.
element /PM_CT/lost+found -none
The "elegant" way consists of:
adding a selection rule (here "-none")
loading all PM_CT without aking any question (load /PM_CT), if your view is a snapshot one
Note: in a config spec, always use "/": it is easier, and Windows as well as Unix ClearCase views will be able to interpret it.
Caveats:
the previous solution is for one vob, I do not think you could use "wildcard" for multiple vobs
the '-none' option can cause a snapshot view to fail during a deliver or rebase (UCM merge): for that kind of operation, a dynamic view would be more suited. That is for CC 2003.06 and early 7.0. I think it works better with the latest CC7.1.0.2
Note: that selection rule can also be used for dynamic views, in order to mask some directory you would not want to see.