I have a question about clearcase, someone helped me on some issue in clearcase, he used a command as follow: echo " " > xxx.log and
cleartool co -nc filename
what does this mean?
When you have a file which is "checkedout but removed", as described in ct ls:
The element was checked out in this view, but the view-private file was subsequently removed.
You may have deleted the file.
A solution to restore that file is to checkout it again, but if you do that directly, ClearCase would complain about being unable to access said file (because it isn't physically there anymore).
Hence the:
echo " " > afile
You need to have some content in that file in order to make a cleartool command on it.
So even if its content is a bogus one, it at least allows you to proceed.
Then, you can checkout it again (-nc means without comment, but it also means "takes the previous comments used on the current checked out version)
cleartool checkout -nc afile
Another way to restore it is to uncheckout the file:
cleartool unco afile
That will also restore its content.
The first command writes a space to xxx.log; echo is a shell command and has nothing to do with clearcase. The second command checks out filename without comments. These two commands seem to be pretty unrelated, unless there something else you haven't told us.
Just a tip:
'echo' might to used to clear xxx.log file.
co - stands for check out filename,
nc - stands for no comments
Might be helpful: http://www.yolinux.com/TUTORIALS/ClearcaseCommands.html
Related
In the clear case, I want versions of the file in the particular directory with complete file path. By right click on the file and after that going for properties in the file it is possible to take, but in case in the directory 100 files are there, so it will become very huge task. I want to know the clear tool command , which i can execute from the command prompt and after that I can redirect output to some text file
Example of path I am using:
M:\My_Project\Verif_Folder\TP\Functional_TP\ETP\ here
Check the command cleartool find, combined with a cleartool describe and fmt_ccase option:
cd M:\Myproject\...\here
cleartool find . -type f -exec "cleartool describe \"%CLEARCASE_XPN%\" -fmt \"%Xn\""
%Xn: Extended name: Same as default
%n output, but for checked-out versions, append the extension ##\branch-pathname\CHECKEDOUT
The result will be the path of the file, its name, and its extended path including its current selected version.
To provide some context, I am trying to write a script which will take a text file with clearcase elements in it, and label all of those elements.
To generate the text file, I am basically using the following command:
cleartool find -a -nxn -ele "brtype(branchName)" -print > "textfile.txt"
Then I go through the text file and remove the elements I don't want to label. The last step would be to feed the text file into a script which would repeatedly call a cleartool command on each line of the file.
For all existing files/folders, I can run this command:
cleartool mklabel -rep "label_name" (element_path)
Where I run into trouble is with files that have been added to the branch. They print out to the text file in a format that isn't recognized by the "mklabel" command and I can't find a good way to parse them.
The format of the files is similar to the following:
\original_folder_path##\branch_name\version_number\new_sub_folder_path\branch_name\version_number\file_name.java
In the past I have used this generic command we use at my company to blindly label all files in a branch:
cleartool find -all -branch "brtype(<branch>)" -version "version(.../<branch>/LATEST) && !version(.../<branch>/0)" -visible -exec "cleartool mklabel -rep <label_name> %CLEARCASE_XPN%"
But I only want to label about half the files on the branch I am using, and there are too many to label them individually. I am sure I am missing something obvious here. Does anyone know how I should change my find or mklabel command to accommodate the new files and folders?
That format "\original_folder_path##\branch_name\version_number" is an extended pathname, and isn't reserved for "added file".
It is current rather for files listed by a cleartool find, but not visible (directly accessible) in the view used by the cleartool find.
You need to make sure to use a view which is set to select the LATEST from brname.
If you see extended pathnames in your cleartool find, you can ignore them: they are not accessible by said view.
Or you could use a cleartool find -cview, in order to limit the results to what you view is able to select and see.
Let's say there is a file called myfile.java. I checked it out and I was working on it. Before checking it in, I have lost my hard drive and I had to get a new hard drive.
Next time that I want to check out the file, it says that I can not check out. It was already checked out in the old view which has gone. I have to mention that I am using the option "re-use development stream option".
Is there anything I can do to be able to checkout the file once again?
You can completely unregister your old view in the vob of that file: that will remove the "checkout" status associated to that file.
cleartool mount \myVob
cd m:\mynewView\myVob
cleartool rmview -force -uuid old_view_uuid
To find the uuid of your old view, try a:
cleartool descr -l vob:\myVob
And look for a view storage path including your old view name in it.
So I'm writing a script at work where I have to go through all the projects in a ClearCase vob, look for a file and parse some info from said file.
Naturally, I wouldn't want to load every single project so I'm using cleartool to retrieve the unloaded files.
First, I'm using the find command to locate the files. This was my first attempt:
root>cleartool find C:/viewpath -name file.txt -version "lbtype(Version-label)" -print -nr
Viewpath is the path to the project where I'm currently looking for the file. The file I'm looking for is file.txt on the version specified by Version-label.
This gave me no result whatsoever, even though I knew file.txt existed on that version.
I figured out it was looking through an old version of the directory, the latest on the main-branch, which was before file.txt was added to the directory. I tried this instead:
root>cleartool find C:/viewpath##/Version-label -name file.txt -version "lbtype(Version-label)" -print -nr
And got this result, which was what I was looking for
C:/viewpath\file.txt##\main\branch\41
So now that I knew where I could find the file I tried to get it.
root>cleartool get -to savepath C:/viewpath\file.txt##\main\branch\41
Which gave me this result
cleartool: Error: "C:/viewpath\file.txt##\main\branch\41" does not exist, or is not a ClearCase version, or is a checked out version which was removed.
Also tried
root>cleartool get -to savepath C:/viewpath\file.txt##/Version-label
With the same result
I can get files added to the directory when it was still on the main-branch, so it is still searching through the directory on the main-branch, where file.txt is nowhere to be found.
How do I tell it to look through a version of the directory from after it was branched from main?
I would really recommend for you to try those same commands in a dynamic view.
As illustrated here, a dynamic view gives you access to extended path (the file##/branch/version syntax), which means command like get will work.
You have in this question an example of search (cleartool find) using extended paths.
As explained in "In ClearCase, how can I view old version of a file in a static view, from the command line?", you can browse (as in 'change directory to') the various extended paths of a file in a dynamic view.
I am trying to delete a file in ClearCase. When I attempt to delete it I get a message that the element has checkouts. When I do a version tree on the file I see that the file is checked out by another user, in another view, on a different branch.
How do I delete this file? In addition why doesn't ClearCase let me delete this file?
You can delete it through the command line and cleartool, by forcing its delete (option which isn't available with the GUI)
cleartool rmname -force theFile
Don't forget to checkout the parent directory first, then to checkin that same parent directory, in order for everyone to see that you have dereferenced that file within said directory.
See cleartool rmname:
–f/orce:
Forces the removal of the name when there is at least one checkout of the element.
When used with –nco, suppresses the prompt for confirmation.
That will work even when you had this before:
, as explained in the technote "About cleartool rmname and checkouts".