I'm trying to hide an element in my ClearCase view. I've set the following line in my config spec:
element /path/to/some/element -none
Further down in my config spec, there is an include to another config spec (which in turn includes other config specs and so on - a complete mess, but I can't change this). I'm pretty sure there is another line in there setting this element to a tagged version. When I do ct ls on the file I see:
/path/to/some/element##/main/1 Rule: SOME_TAG
Is the -none option to element overridable by a tag? If so, how can I work around it?
I confirm a config spec wouldn't operate well through a symbolic link.
See config spec man page
There is no VOB symbolic link scope.
A VOB symbolic link is cataloged (listed) in one or more versions of a directory element
A vob symbolic link adds some issue with the config spec (seen for instance after relocating elements)
Even without talking about Vob symlink, this technote mentions that ClearCase config spec without an unrelated wildcard or unrelated recursive rule will not resolve the end point of a symlink.
What dawned on my was that the path to the element contained a link to another VOB. After I changed the path to the absolute path of the other VOB, it worked:
element /var/vob/other_vob/vob/path/to/some/element -none
Apparently config spec settings don't apply through links.
Related
Background
In ClearCase, you can make unreserved checkouts if a certain file is already checked out by another view with the following command:
ct co -unreserved <element>
You can also add a new element to clearcase with the following command
ct mkelem <new_element>
However, using the mkelem command on a file requires that the directory of the file be a checked-out clearcase element.
Issue
I am trying to create a new clearcase element in a directory. This directory is current checked out by another view, thus I need to make an unreserved checkout. The unreserved checkout works perfectly. However, when I try to run ct mkelem newFile after making an unreserved checkout of the directory, I get this error:
% ct mkelem newFile
Creation comments for "newFile": . Created
element "newFile" (type "text_file").
ERROR: User [user_name]
cannot make reserved checkouts for this file type or branch in this area. File
is [/vobs/directory/to/newFile##/main/0] You can still
make an unreserved checkout if needed.
Which lead me to wonder...
Question
Is there a way to make a new clearcase element inside an unreserved checkout of a directory?
This seems to be a custom error message: "You can still make an unreserved checkout".
Meaning it is not natively displayed by ClearCase.
So check if there are any VOB trigger in place which would enforce such a policy (no unreserved checkout of a directory): use cleartool lstype -invob \aVob -kind trtype, as in this answer.
Because you can checkout a folder concurrently in a reserved and unreserved way... which can lead to evil twins, as this thread illustrates:
evil twins were introduced from users in parallel directory versions, either from another branch or different versions in the same branch (a user had an old unreserved checkout, added a file that another user already added in a reserved checkout later in the version tree, thus you now have evil twins.)
I would like to be able to identify symlink in clearcase. I am generating queries from an oracle database containing the clearcase extended path of element versions. It is working well for actual elements, but for symlink, the query is returning me the extended path name of the target (and attributes).
Is it possible to change the behavior of describe command ?
Or at least to identify VOB symlink from the extended path ?
Note that the oracle database should not include symlinks.
From "About symbolic links and version-extended pathnames"
Symbolic links are not versioned and, hence, do not have version-extended pathnames.
Symlinks are not catalogued in the version history of the element.
They serve only as a pointer to a target version, and allow you to create multiple access points to a single version.
The symlink can be described (cleartool describe) with a simple pathname, as follows:
%>cleartool describe -long yoda
symbolic link "yoda" -> ../yoda.txt
The actual text file that the symlink points to can be described with a simple pathname or using its version-extended pathname:
%>cleartool describe -long yoda.txt##/main/br1/br2/1
version "yoda.txt##/main/br1/br2/1"
I get this error while I try to load a new snapshot view with my own config spec (this is base ClearCase).
cleartool error: Unable to load "filename.exe": no version selected in configuration
specification.
If I try to load a dynamic view with the same config spec - I can
see this file (that can't be loaded). The selected version does exist on the config spec (of the snapshot view as well).
If I change the config spec of the snapshot view (to default config spec) I can load all files with no problem (but on the other hand, the missing file is not loaded since it's not part of the config spec).
What goes wrong? Can you advice please?
Thank you
The easiest way to debug this is to do a:
cd /path/to/snapshot/view/avob/parent/directory
cleartool ls
cd /path/to/dynamic/view/avob/parent/directory
cleartool ls
That allows to check:
the status of the file in both views
if the other files in that folder are selected with the same versions.
I am new to Rational and I have to add functionality to an existing program to support a new program. The applications are small and in a directory structure, they are on the same level. What I would like to do is - when I perform a CheckOut under the legacy application the files are checked out under a new branch. When I check out under the new application, the files are checked out under the standard /main branch. Here's kinda what it looks like:
/main
/CGI_Legacy
/CGI_Extended
/NewApp
It is my job to create the CGI_Extended and NewApp applications. CGI_Extended represents the new branch.
Thanks
Don't mix directories and branches.
Branches are set in the config spec of a ClearCase view, which, for base ClearCase view, would look like:
element * CHECKEDOUT
element /MyVob/Legacy/... .../CGI_Extended/LATEST
element /MyVob/Legacy/... /main/LATEST -mkbranch CGI_Extended
element /NewApp/... /main/LATEST
See also:
"How config specs work"
"Writing config specs "
This won't create a directory CGI_Extended, and will keep the files in their original directory, but will create an new branch CGI_Extended on each checkout.
In our clearcase we are having few folders require same contents.
We use to have symlink to achieve that. But Now our folders are having view private files, so symlink doesn't do any good.
Is copying it again the only mechanism ?
Any other policy or settings which can help to symlink view private file?
Symlinks (OS symlinks, not cleartool symlinks) should be supported, even for private files (they would certainly work in snapshot view anyway: those are based on the native OS).
Otherwise, copy is still a solution to fallback on.
But I am not aware of any dedicated policy on ClearCase for symlinks on private view files.
The is only one policy for versionned symlinks (created by cleartool ln -s, but this isn't your current scenario):
On Linux and UNIX systems, symbolic links are listed as absolute pathnames by default.
To list symbolic links as relative pathnames, set the environment variable CCASE_LS_RELATIVE_SYMLINK_PATH.
The OP Samselvaprabu mentions using Dynamic view drive and i am in windows environment, and reports the following error on symlink creation:
Object Msilist.bat is not a valid symlink target; no symlinks will be created.
Please select only valid symlink targets and retry the operation.
The man page "To create a Vob symlink" mentions the following restrictions:
You can use the cleartool ln -s command to create a VOB symbolic link (symlink) to the following items:
A file or directory (checked in or checked out)
A symbolic link
An eclipsed element (dynamic views only)
A hijacked element (snapshot views only)
The target of the symbolic link must be in the same view as the directory in which the symbolic link is to be created.
If you are in a snapshot view, unloaded elements are not valid symlink targets. Also, the directory in which the symlink is to be created must also be loaded.
My point was:
If cleartool ln -s doesn't work, especially for private file (which are not in ClearCase anyway), use OS symlink (in your case, NTFS symlinks if you are on Windows Vista or more, otherwise simple junction points)
So OS symlinks (native symlinks, not created by cleartool) should work.