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
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 am trying to create/update view using ClearCase, but while downloading it gets struck and exits without creating the full view.
Is there any workaround to either skip the files and download manually?
Please suggest.
In order to troubleshoot that kind of error message, it can be helpful to reproduce the snapshot view update in command line to see if any other error message pops up (cleartool update).
cd C:\CCSS1\UT_ISR
cleartool update -print -log C:\temp\log.txt .
If it is not a path length issue, check if the view storage path is accessible (the one starting with \\... redacted in the pictures)
Check the characteristics of that view
cd C:\CCSS1\UT_ISR
cleartool lsview -l -full -pro -cview
Check the logs:
cleartool getlog -last 20 view
Check if the issue persists after reboot (in case a process might currently keep an handle on a resource which would then be blocked and updated)
The OP dodger mentions in the comments:
I was able to overcome the problem by downloading files that were only pertinent and rest I skipped.
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".
Today we faced weird issue in Clearcase UCM.
We were trying to add a folder named "Common" (which has many subfolders and file elements).
When we click on add to source control , it doesn't show up activity list box. (it is displaying as if we were trying to add to source control in base clearcase).
When we cancel it ,it threw exception and changed the folder name first as small letter (common). If we try to add this to source control, It displayed activity list.(like normal UCM add to source control dialog).
We checked the case preservation check box in cc.cpl then restarted the services. but still we faced the same issue.
We are using latest clearcase and OS is Windows 7. I am not sure why this occurs . It stopped us to add source control with the name "Common".
what could be the issue ? If you have faced this and solved it , please guide me.
The usual recommendation, whenever strange errors are happening though the GUI, is to fallback to the CLI.
See:
"To add elements (files and directories) to source control from the command line"
cleartool mkelem
You can do:
# go to the parent directory of Common
cd <view/path/to/Common>/..
# check there is a current activity set
cleartool lsact -cact
# checkout the parent directory
cleartool checkout -nc .
# add to source control Common (not its content, just the directory)
cleartool mkelem –nc -ci -ptime –eltype directory
# checkin the parent directory
cleartool checkin -nc .
I have CM Server for ClearCase Remote Clients in windows 2003 server.
Installed package in server.
I'm getting below error in CCRC client:
"CRVAP0087E CCRC command "checkin" failed: Unable to create pathname for
file "C:\ccweb\v973012\v973012_Latest_FMC": Permission denied"
Can you please help me to fix this issue?
The most efficient way to troubleshoot right issue is to go directly to the CCRC server, under the CCRC web (snapshot) view and type:
cd c:\ccweb\v973012
cleartool lsview -l -full -pro -cview
That way, you see with which group the user has created the CCRC view in the first place.
That group must be one of the groups associated with the Vob of the element being checked-in.
Check also this technote:
During the installation of Rational ClearCase, you are asked for a temporary directory to use during the installation to unzip large artifacts.
This temporary directory is used to preserve user configuration settings during an update or uninstall process.
If you specify a directory that is mounted on a file system that is separate from the installation directory, the file permissions and owners are not preserved when the files are moved across the file systems.
Finally, check for any trigger set on the Vob: they can have an unwanted side-effect with that CCRC 'checkin' operation.
In the specific case of the OP mth123, he suggests:
Go to the Windows Explorer and try these steps:
Go the the following directory: C:\ccweb
Rename the folder v123412 to V123412 (Only change the first letter and put "V" capitalized.)
Check if the problem is solved.
So depending on the actual tag of the view, this could be an issue about case-sensitive path.
The latest patch caused this issue. While applying patch CC preserving some file inclusing ccweb folder. while restoring those folder during post install these directory might have changed with lowercase/upper case. This is currently with IBM queue.
If you are going to upgrade CCRC please make a copy of ccweb directory with proper ACL or use ccopy.exe (clearcase utility)