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"
Related
My eclipse suddenly shut down, and after that for a particular file, there are two files present:
the main file and
a .checkedout version of it.
Now the main file is not checkedout out from my machine, still if anyone else tries to check out the file: it shows it is checked out already.
I have seen from Clearcase explorer too, it is the same there.
Any solution for this?
It depends on the version of ClearCase (client and server, including their OS), and of the type of ClearCase view you are using (snapshot, dynamic, web view)
But in general, if a file is checked out and should not be, you can delete any checked out status associated to your view.
However, please note it will cancel all your checked out files done in this particular view (for that particular Vob), so make sure it won't impact your current work in progress (save it first elsewhere to be safe).
cleartool descr -l vob:\myVob
# get the uuid of the user's view from the description of the vob
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
Note: you can also get your view UUID with
cd path/to/my/view
cleartool lsview -l -full -pro -cview
That way, nobody else will see any of your previously checked out file as "checked out".
Note that a .checkedout file is typically the result of a failed checkout for permission issue.
Example:
Unable to rename "M:\myView\myVob\path\to\afile.png" to "M:\myView\myVob\path\to\afile.png.keep": Permission denied.
Checked out version, but could not copy data to "M:\myView\myVob\path\to\afile.png" in view: File exists.
Correct the condition, then uncheckout and re-checkout the element.
Copied checked-out version data to "M:\myView\myVob\path\to\afile.png.checkedout".
Checked out "M:\myView\myVob\path\to\afile.png" from version "\main\myStream\0".
Attached activity:
activity:deliver.stream_myStream.20120426.115512#\myPVob
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 am new to clearcase and I am trying to generate a blame file using annotate command, but I am getting the following error :
cleartool: Error: Not an object in a vob: "App.java"
I followed these steps :
Created a view in clearcase explorer
Browsed to the location (C:\test_view)
Ran: cleartool annotate App.java
This resulted in the following -
cleartool: Error: Not an object in a vob: "App.java".
You cannot execute cleartool commands on elements (versioned files or folder) directly in a snapshot root folder like c:\test_View.
You need to edit its config spec:
cd c:\test_View
cleartool edcs
Add selection rules (like at least element * /main/LATEST, unless this is an UCM view, in which case selection rules are already there), and load rules in order to load at least the content of a Vob.
Then you can go within the vob and do some cleartool annotate.
cd c:\test_view\avob
cleartool annotate afile
Note: if your file App.java is not yet versioned, you would need to add it to source control (in any folder in c:\test_view\avob), with cleartool mkelem, or, for multiple files, clearfsimport.
Please create VOBs through create VOB program.
Then create dynamic view using clearcase explorer.
Mount the VOBs on the dynamic view.
Once mounted, in the view explorer, right click and add text file.
rt-click text file to add to source and then checkin the file after making the necessary changes.
from command prompt go to the VOB and run
cleartool annotate
Z:>cd test_tut_element_vob
Z:\test_tut_element_vob>cleartool annotate TestFile.txt
Annotated result written to "TestFile.txt.ann".
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.
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.