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.
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.
I have a view, for some reason, it was named with a special character: "0x7f", at least I think so..
For example:
MyView123456 -> MyView'0x7f'123456
I can only found this view by
ct lsview #list all views.
And I found this "0x7f" when dump the outputs to a file.
And using vim.
Now I'm trying to delete this view totally.
I can unregistered and delete the view itself by -uuid.
But I cannot delete the view tag.
And I also found wildcard '*' seems not working.
Does anyone know how to delete this view tag?
P.s. I'm under Linux, and no GUI.
Try first if dome of the workaround described in "Removing ClearCase objects whose name begins with a hyphen", when using cleartool rmtag:
cleartool rmtag -- MyView*
Note the use of '--' in order to separate the command from its parameters
The wildcard being expanded by your shell, try and use it instead in the cleartool interractive session:
cleartool
> rmtag -- MyView*
In Linux shell, see if a single quote is enough:
cleartool rmtag -- MyView'0x7f'123456
# or
cleartool rmtag -- 'MyView0x7f123456'
I was able to create and remove a view with binary data in the tag using Perl. You have to use the OCTAL value of 177 in the strings.
I created my view using this command line:
perl -e '`cleartool mkview -tag myview\177tag /net/bullwinkle/export/vobstg/binarytag.vws`'
And I successfully removed that view tag using this command line:
perl -e '`cleartool rmview -tag myview\177tag`'
If the view was unique enough, you could also use (on Unix) or at least try:
cleartool rmview -tag `cleartool lsview 'myview*123456'`
There is another mechanism, if all else fails: you can edit the vob_tag registry file. This would require an outage as the registry file is loaded into the registry server's memory on clearcase startup and only re/written after that point.
The process is:
Stop ClearCase on the registry server
CD to /var/adm/rational/clearcase/rgy (Unix) or {CC Install dir}\var\rgy (Windows)
Back up the vob_tag file.
load the vob_tag file in an editor. (vi/gedit on unix, but I'd use notepad++ on windows)
locate the problem view tag (you may need to search on the global path or some other component of the name).
Make note of the path to the view.
Delete the line.
Start ClearCase on the registry server
unregister the view or retag it with an easier-to-access tag.
I can compare two files in Winmerge by triggering a comparison on the command line with a command similar to:
WinMergeU C:\file1.txt C:\file2.txt
I can query a list of files with particular properties in clearcase with a clearcase query similar to:
Y:\VOB_A>cleartool find . -type l -exec "cleartool describe -fmt "%n %[slink_text]Tp\n\n\" \"%CLEARCASE_PN%\""
.\Directory\createsymlink.txt -->..\..\VOB_B\SymlinkFolder\createsymlink.txt
What I want is to generate a set of clearcase query results that can then be used as input to winmerge (ie generate a bunch of diff commands on checkins fulfilling a certain criteria like user or day).
How can I write a clearcase query to get a list of file elements (referable in clearcase ie winmerge could open the path to the version on a dynamic view), and get their corresponding previous version of the file?
The bit to format this to winmerge I imagine would look somewhat like this:
... describe -fmt "WinMergeU ...
One, you would need to generate the right full extended pathname for each file (one being the result of your query, one being the previous version of the one found by said query)
Two, you need to do so in a dynamic view (in order to access to any version though the extended path name of the file.
Once your query gives you a version, you can ask, with a cleartool descr -fmt "%PSn" (see fmt_ccase man page), for the previous version and add that to your result file.
Trying to do it all in one pass (find + predecessor version + WinMerge call) seems too complicated.
I need to retrieve a list of all the files that have been checked-in across baselines along with the owner name. I tried using the cleartool lsact command :
However, this command fetches just for one task and is a bit cumbersome to use. Is there a command which will retrieve all the tasks if I specify two baselines?
Thanks
A command like:
cleartool diffbl -act bl1#\apvob bl2#\apvob
will give you the list of activities which have new versions between baselines bl1 and bl2.
However, to get the list of files (ie elements, as in files or directories, and not versions as in all the updated versions even for a same file), the best way is to:
ensure those baselines are "full" baseline: promote them to full if needed:
cleartool chbl -full bl1#\apvob
cleartool chbl -full bl2#\apvob
(if they were already full, this command won't do anything)
list all elements which have the bl1 and bl2 labels on different versions:
cleartool find -all -element '{lbtype_sub(REL1) && lbtype_sub(REL2)}' ^
-version '{(lbtype(REL1) && ! lbtype(REL2)) || ^
(lbtype(REL2) && !lbtype(REL1))}' -print
See "Find changes between labels".
Note that this last question also mentions the "report builder packaged with ClearCase, which is interesting if you are after a solution involving a GUI and not a CLI (command line):
Again, if those baselines are full, you can use it to list (under Elements/Labels) either "Elements Changed Between Two Labels" or "Versions Changed Between Two Labels" depending on which you need.
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.