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.
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 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"
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 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)