I'm trying to commit a number of files
rcleartool.bat ci file1.cxx file2.cxx
only file1.cxx is checkedout
file2.cxx is hijacked
This commit checks in file1.cxx but leave file2 unchecked in giving me a warning
Is there a way to say "check in all files, including the hijacked ones I supply on the command line" or do I have to go through all the hijacked files, check them out and immediately check them back in?
Many thanks in advance
Since the cleartool checkin command does not mention hijacked files, you would need two passes:
one for converting hijacked files in checkout files with checkout -usehijack
one for checking, which will does nothing for the hijacked files,
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
In clearcase v9.0.1.5, I need to import files from folder A to new folder B with the latest version of A.
Meaning: the ClearCase versions of files in B should be same as that of A:
if file version in A is 4 then after import the version of that file should show as 4 in B.
Is there any possibility to perform this ?
You can easily use clearfsimport to import flat files to a branch in one command.
That will duplicate the files from A to B, versioning them again in B.
But that won't duplicate the version number, which entirely depends on the history of the branch.
You can use cleartool checkin -identical to force an element to increment its version number on its branch.
If folders A and B are in the same VOB, you can hard link the files together, but that will have issues with checkouts in dynamic views. You could also create use symlinks.
If A and B are in separate NON-UCM VOBs,you can use clearexport_ccase and clearimport to copy the elements.
Another option for non UCM VOBs is to use relocate -update to copy the files. This clones the relocated elements completely, down to their OIDs. If A and B will be used in the same audited build, you probably dont want to do this as some directory OIDs may get cloned too, and directory element OIDs are used heavily in build audits.
For UCM component VOBS, you may have to DIY it using scripts. "Cleartool checkin -from" may help here.
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.)
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.
If a folder is deleted from clearcase and then when I "update from repository" should the folder be deleted locally also ? Currently it is not deleted locally, I have updated my view and can see the folder has been removed from the view.
No, by default, a cleartool update preserve private content.
And your directory is now considered private, once removed from ClearCase from another view.
(which is your case here: you didn't delete it directly in your view from the ClearCase interface).
You could see your directory renamed as 'yourDirectory.unloaded', but sometimes it will remain unchanged, especially if some process has an handle on it.
See technote "About .unloaded snapshot view files" for more.
The help page "How files and directories in snapshot views are unloaded" mentions:
Unloading directories
Directories are unloaded recursively.
To unload a directory element, the files in the directory are unloaded.
If any view-private objects, hijacked files, or checked-out files are in the directory, or if the directory is currently in use (for example, if your current working directory is in or below the directory) .unloaded is appended to the name of the directory.
For example, if the directory src contains view-private files, the directory is renamed to src.unloaded.
In your case, you need to make sure that no process has any handle on the directory itself or the directory content, make your update (-overwrite has no bearing here, being only there to restore hijacked file), and then search and remove any *.unloaded elements (files or directories).
As far as I know, delete a folder from clearcase interface , local file will also be deleted.