I have somehow created a branch of a file in clearcase UCM that is not part of an activity. I have no idea how to reproduce this, but my stream is showing many files with this symptom. How can I find these files, remove them, and prevent it from happening again in the future?
Here is an example of one such file, names redacted to protect the innocent:
xxxxxxxxxxx.cpp##/main/xxx-integration/xxxxxx-xxxxxxxx/0 Rule: .../xxx-xxxxxxx/LATEST
A ct lsact -long | grep <filename> returns no results.
Update:
I used a find command to track down all the files that are on the branch given (and redacted) above, though I still do not understand the issue.
Per VonC's answer, where is what I ended up doing:
cleartool find . -type f -version "version(.../xxx/LATEST)&&version(.../xxx/0)" -print | tee ~/tmp/files2
I then read through the list of files generated to make sure they made sense, then I verified they were not attached to an activity and removed the versions:
cat ~/tmp/files2 | while read
do
if [ -z "$(ct describe -fmt "%[activity]p" $REPLY)" ]
then
ct rmbranch -f ${REPLY%/0}
fi
done
That can happen ig those file were checkout in a base ClearCase view, ie a non-UCM view, withg a simple config spec:
element * .../xxx-integration/LATEST -mkbranch xxxxxx-xxxxxxxx
You can use a find command similar to "How can I find all elements on a branch with version LATEST that has no label applied?".
The difference is: for each version found, you need to describe it in order to check if there is an activity attached to it or not (with a fmt_ccase):
cleartool describe -fmt "%[activity]p" "$CLEARCASE_XPN"
Related
I want to find in which ClearCase label a specific string was added in code?
I am using base ClearCase.
I recommended before (8 years ago) to limit the scope of your search and use the exec clause of a cleartool find.
Example:
cleartool find -all -type f -user myLogin \
-version "lbtype(A_LABEL)" \
-exec ...
If you can do so in a dynamic view, you can then directly grep the content of CLEARCASE_XPN, the variable set by cleartool find for each version found.
It reference an extended pathname that (in a dynamic view) you can directly read and grep for your code)
You can do so for each label you can find in your Vob, from the oldest to the newest.
Z:myvob>ct lstype -kind lbtype -short
Z:myvob>ct find . -version "lbtype(A_LABEL)" -print
If you are looking for a specific change in a given source file, the cleartool annotate command will give you a good start. If you're familiar with GIT, this is the equivalent of "git blame."
Annotate works only if the element is one of the text file types (text_file, utf?_text_file, etc.) since those store delta information on a per version basis.
One caveat is that this will tell you what version the change came from, but if that version was created by a merge, you may have to backtrack the merge to find the original location of the change. ALMToolbox's "visual annotate" tool does that for you, if I recall correctly.
I have some files and directories out of which few are already checked out and few are not.
To check out those uncheck out files I am running recursive checkout:
ct co -nc ./*
Which gives below message for already checkout files or directory:
cleartool: Error: Element "abc/xyz" is already checked out to view "pqr".
Is there any way I can avoid performing ct co on already checked out files or directories?
First, you can check if you have the same issue when applying my old method "How do I perform a recursive checkout using ClearCase?".
cleartool find somedir -type f -exec "cleartool checkout -c \"Reason for massive checkout\" \"%CLEARCASE_PN%\""
(which is mirrored by the IBM technote swg21122520)
The other option is to:
first find checked out files (see "How to find all checkedout files with ClearCase cleartool?", without the -cview option, in order to list checked out files in all views)
redirect that find into a file
Then you can replace the -exec directive above in order, for each \"%CLEARCASE_PN%\" found, to:
check if it is listed in the checked out files found in the previous point
if it is not, proceed with the checkout.
In short: a two-step process.
I would like to list the available labels matching a particular string applied in the view.
I confirm a filter in cleartool find is not possible:
ct find . -ele "lbtype_sub(My_LAB*)" -print
would not work (no wildcard in query argument.
If you cannot use a grep in a shell pipe, can you consider using grep in an exec part of a find, like in this example?
ct find . -kind lbtype -exec "echo %CLEARCASE_PN%|grep MY_LAB"
If this is not acceptable, you need to write the result in a file and process it with another tool (sed?)
You have packages for Windows including Unix commands: see this SO question.
Of you have freeware emulating the grep command.
If you must stay with native Windows commands, you must redirect the result in a file, and use FIND (English translation).
Hmm. I'm not entirely sure about this although the following will list all labels used for a given VOB (entered using ClearTool command line application).
lstype -kind lbtype -invob vob_path_and_name -short
for example with a View mapped to drive U: VOB "Some_VOB" would be:
lstype -kind lbtype -invob U:\Some_VOB -short
situation:
one vob, 2 views (main dev and branch view).
i need to find all files that where created in the branch view and therefore can't be found via merge manager.
anyone able to help?
thanks
When it comes to cleartool find, the two sources of information and example I recommend are:
SAMECS find command
IBM find examples
In your case:
cleartool find -all -ele "brtype(mybranch) && !brtype(main)" -print
(supposing "main dev" means "branch 'main'")
cleartool find -all -type f -ele "brtype(mybranch) && !brtype(main)" -print
would limit that to files only (not directories)
In a static view, how can I view an old version of a file?
Given an empty file (called empty in this example) I can subvert diff to show me the old version:
% cleartool diff -ser empty File##/main/28
This feels like a pretty ugly hack. Have I missed a more basic command? Is there a neater way to do this?
(I don't want to edit the config spec - that's pretty tedious, and I'm trying to look at a bunch of old versions.)
Clarification: I want to send the version of the file to stdout, so I can use it with the rest of Unix (grep, sed, and so on.) If you found this question because you're looking for a way to save a version of an element to a file, see Brian's answer.
I'm trying to look at a bunch of old versions
I am not sure if you are speaking about "a bunch of old versions" of one file, "a bunch of old versions" from several files.
To visualize several old versions of one file, the simplest mean is to display its version tree (ct lsvtree -graph File), and then select a version, right-click on it and 'Send To' an editor which accepts multiple files (like Notepad++). In a few click you will have a view of those old versions.
Note: you must have CC6.0 or 7.0.1 IFix01 (7.0.0 and 7.0.1 fail to 'sent to' a file with the following error message "Access to unnamed file was denied")
But to visualize several old versions of different files, I would recommend a dynamic view and editing the config spec of that view (and not the snapshot view you are currently working with), in order to quickly select all those old files (hopefully through a simple select rule like 'element * aLabel')
[From the comments:]
what's the idiomatic way to "cat" an earlier revision of a file?
The idiomatic way is through a dynamic view (that you configure with the exact same config spec than your existing snapshot view).
You can then browse (as in 'change directory to') the various extended paths of a file.
If you want to cat all versions of a branch of a file, you go in:
cd /view/MyView/vobs/myVobs/myPath/myFile##/main/[...]/maBranch
cat 1
cat 2
...
cat x
'1', '2', ... 'x' being the version 1, 2, ... x of your file within that branch.
For a snapshot view, the extended path is not accessible, so your "hack" is the way to go.
However, 2 remarks here:
to quickly display all previous revisions of a snapshot file in a given branch, you can type:
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
you can quickly have an output a little nicer with
(one line version for copy-paste, Unix syntax:)
cleartool find addon.xml -ver 'brtype(aBranch) && !version(.../aBranch/LATEST) && ! version(.../aBranch/0)' -exec 'cleartool diff -ser empty "$CLEARCASE_XPN"' | ccperl -nle '$a=$_; $b = $a; $b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;print $b if $a =~/^>/'
(multi-line version for readability:)
cleartool find addon.xml -ver 'brtype(aBranch) &&
!version(.../aBranch/LATEST) &&
! version(.../aBranch/0)'
-exec 'cleartool diff -ser empty "$CLEARCASE_XPN"'
| ccperl -nle '$a=$_; $b = $a;
$b =~ s/^>+\s(?:file\s+\d+:\s+)?//g;
print $b if $a =~/^>/'
That way, the output is nicer.
The "cleartool get" command (man page) mentioned below by Brian don't do stdout:
The get command copies only file elements into a view.
On a UNIX or Linux system, copy /dev/hello_world/foo.c##/main/2 into the current directory.
cmd-context get –to foo.c.temp /dev/hello_world/foo.c##/main/2
On a Windows system, copy \dev\hello_world\foo.c##\main\2 into the C:\build directory.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2
So maybe than, by piping the result to a cat (or type in windows), you can then do something with the output of said cat (type) command.
cmd-context get –to C:\build\foo.c.temp \dev\hello_world\foo.c##\main\2 | type C:\build\foo.c.temp
I know this is an old thread...but I couldn't let this thrashing go by unresolved....
Static views have a "ct get" command that does exactly what you are looking for.
cleartool get -to ~/foo File##/main/28
will save this version of the file in ~/foo.
[ Rewritten based on the first comment ]
All files in Clearcase, including versions, are available in the virtual directory structure. I don't have a lot of familiarity with static views, but I believe they still go through a virtual fs; they just get updated differently.
In that case, you can just do:
cat File##/main/28
It can get ugly if you also have to find the right version of a directory that contained that file element. We have a PERL script at work that uses this approach to analyze historical changes made to files, and we quickly ran out of command-line space on Windows to actually run the commands!
If File is a Clearcase element, and cat File works, and the view is set correctly, then try:
cat File##/main/28
(note: without the ct shell-- you shouldn't need this if you're already in the view.)
Try typing:
ct ls -l File
If it shows the file with an extended name similar to the above, then you should be able to cat the file using an extended name.
ct shell cat File##version