When I execute a "cleartool ls filename##specificVersion", I see
filename [not loaded]
What does this mean?
For background information, I was trying to also execute a cleartool mkbranch, and was a "Element not found" error. So, for a sanity check, I tried a cleartool ls.
"not loaded" means the file:
is selected (by the selection rules element * ...) but:
not loaded by the load rules (load /xx/yy...)
You can see both sets of rules by doing a cleartool catcs anywhere within your view (or cleartool edcs to edit said rules)
This is typical of a snapshot view, which is the only one having "load rules" (as opposed to a dynamic view)
See:
"Before accessing files not loaded into snapshot views":
A snapshot view contains only the set of elements that you specify in the load rules of your view. (In UCM, by default, your view loads all of your project source files.)
When you restrict the scope of a view, it contains only a subset of elements in the VOB. During the course of a development cycle, you may need to see a version of an element that is not loaded into your snapshot view.
You can view nonloaded files or copy them into your view for build purposes, but you cannot check them out. Only file elements that are loaded into your view can be checked out.
"To copy a nonloaded element into a snapshot view"
cleartool get -to filename path
cleartool get -to prog.c.previous.version prog.c##/main/v3.1_fix/10
Related
I have created a symbolic link (see below) to a version controlled file from a different vob (VOB_II) and the file is visible from a dynamic view whereas it’s not visible from the UCM snapshot view.
A.txt --> ..\..\..\VOB_II\SampleDir\A.txt
I have the following selection and load rules.
element \VOB_II\SampleDir\A.txt ...\branch1\LATEST
load \VOB_II\ SampleDir
Any ideas why the file is not getting loaded in the snapshot view? I could not figure out what’s wrong. Any help or inputs are much appreciated.
First, do a cleartool ls in C:\path\to\my\view\VOB_II\SampleDir
The status can explain why the element is not loaded.
Typically, you need selections rules that selects also the parent folders (SampleDir and Vob_II) before being able to select A.txt.
I would recommend at least adding an element * /main/LATEST (stop rule)
element \VOB_II\SampleDir\A.txt ...\branch1\LATEST
element * /main/LATEST
load \VOB_II\ SampleDir
Second, it looks like you are trying to load the actual A.txt (the one in VOB_II\SampleDir\A.txt), and not the symbolic link one the A.txt pointing to ..\..\..\VOB_II\SampleDir\A.txt
I don't know where is that symbolic link A.txt. In Vob_I?
Third, see "Symbolic links in snapshot views"
Snapshot views created from Linux or the UNIX system maintain standard symbolic link behavior.
In the context of loading a snapshot view, links are treated as:
VOB links (those that point to objects inside the VOB) and
non-VOB links (those that point outside the VOB).
Hard VOB links are followed; symbolic links are copy-created.
If a VOB link cannot be resolved, an error results.
Non-VOB links are resolved, if possible, but it is not an error if they cannot be resolved.
Snapshot views created from a Rational ClearCase host running Windows software do not support links.
VOB symbolic link behavior is approximated in the following ways:
If a load rule selects a symbolic link, the link target is copied into the view at the link path.
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.
Is it possible to remove a dynamic view out of a particular clearcase region?
cleartool -rmview seems to not take a e.g. -region parameter and I was wondering whether there's a more elegant way to achieve this.. or is the only way to change the system's CC settings?
If you want to remove a view from a region, that means you don't want to erase it completely, as it still has to work in other regions.
In that case, the right command is:
cleartool rmtag -view -tag dynamic-view-tag -region theRightRegion
See rmtag command:
The rmtag command removes one or more entries from the network's view tag registry or VOB tag registry
A rmview would both math a rmtag, and un-register the view id (and remove any local trace of the view, like removing the view storage).
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.
What is the difference between Config specs and Load rules in Clearcase?
Are both of them edited using "cleartool editcs -tag " command only?
A config spec is a collection of:
selection rules (for selection the right versions)
load rules (only for snapshot view) for loading into your "workspace" (the snapshot view) the files selected by... the selection rules just above!
You can edit both with ct edcs (just "ct edcs" if you are anywhere in a ClearCase view).
Of course, in a dynamic view, you will only edit selection rules, since there are no "load rules":
there is nothing to "load" on your disk, since the all point of dynamic view is network access to data (very quick, and dynamic as in "automatically refreshed" if the selection rule is on "LATEST" of a branch).
Simple tricks with load rules:
a/ Use "/" even on windows
No need of load \myVob: load /myVob works too
b/ Use them in combination with "cleaning selection rules":
a selection rule is a rule at the end (before the loading rules) which selections nothing
element /myVob/* -none
Since other selection rules placed before that one does select several sub-directories, that last selection rules only means: "if it is not previously selected before, do NOT select it at all".
Consequence for a snapshot view?
Instead of writing:
load /myVob/a
load /myVob/b/b1
load /myVob/b/b2
# do not load /myVob/c
# do not load /myVob/d
load /myVob/e
(because you only want specific directories within /myVob), you can just write:
load /myVob
One simple load rule: it won't load what is not selected. and since "/myVob/c" or "/myVob/d" are not selected, they will not appear (even empty) on the disk within your snapshot view.