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.
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
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".
One says an hijacked file is a file where the "Read Only" flag has been removed.
I tried to remove the "Read Only" flag (Windows) and ClearCase does not recognize it as hijacked. Then I tried to touch the file using Cygwin without actually changing any mode flags. This time ClearCase warns me, we've got hijacked!
It seems ClearCase only look at the timestamp of files not their content and not their read-only flags. This mechanism has a very bad side effects when working in parallel with git. For example, if I do this:
git checkout bar
git checkout master
It would be the same as:
touch foo
Thus, ClearCase will think foo was hijacked which is not the case. For huge projects, this would be very dramatic and unfortunately I always use git to quickly switch to back and forth in my snapshot view.
What would be a good solution in my case?
EDIT
A much more dangerous example would this one:
stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
echo "ClearCase will not see this" >> foo
source restore_timestamp
rm restore_timestamp
When I work in parallel between ClearCase and Git, I don't touch to the git repo within ClearCase: I clone it elsewhere and work from there.
Actually, I don't create a git repo in the ClearCase view directly: I create it outside, adding in it all the file from the ClearCase view (using just for the initial add: git add --work-tree=/path/to/CC/view)
When it is time to synchronize the ClearCase snapshot view with the git working tree, a do a clearfsimport (as in this answer) from that working tree to the ClearCase view: obnly the modified files are checked out/updated and checked in.
That way, I completely bypass the "hijacked/not hijacked" issue.
I'm using the Clearcase Remote Client 7.1.2 (and I only have it available)
I have a file which has 2 branches, branch1 and branch2. branch1 is configured to be the default branch in config spec. I want to checkout a version of the file from branch2, but there is no such option in Version Tree Browser when I click any version of the file on branch2. I can only checkout the latest version on branch1.
What am I doing wrong? Is there a configuration that will allow me to checkout any version I want?
A (CCRC web-)view is always defined to work at the latest version possible (LATEST) of a specific branch.
The CLI associated with CCRC doesn't include 'get' (presented in the second part of "In ClearCase, how can I view old version of a file in a static view, from the command line?"
If your view isn't an UCM view, you could add a selection rule at the start of your config spec (See CCRC edit config spec):
element /vob/path/to/file .../branch2/x
with x a version number from branch2.
However, I don't remember if you have access to the actual config spec source with CCRC.
You may want to create two views. One whose config spec selects versions in branch1 and another that selects versions in branch2. Use the appropriate view when checking out files.
When updating my clearcase (snapshot) view I get the following symlink errors:
Unable to resolve symlink
"setups.cmd". The symlink
target will not be loaded.
Unable to resolve symlink "setup.sh".
The symlink target will not be loaded.
Unable to resolve symlink
"setupwithdomain.doc". The
symlink target will not be loaded.
What do I do or tell my admin to do to get rid of this errors.
Are you on Windows? And with which ClearCase version
There is this IBM Technote, which explains why attempts to create an IBM Rational ClearCase symbolic link on Microsoft® Windows in ClearCase Explorer from a snapshot view fails when the snapshot view root is created with a lower case drive letter.
But that would only be for CC2003.
This thread mentions a similar issue:
We have had problems resolving symlinks when loading snapshot views.
It appears that the resolution of the pathname to the linked file is case sensitive.
The solution for us was to ensure that all symlinks used the correct case for the pathname to the linked file.