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
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 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"
As we are having many components , I am trying to describe all the baselines using following command
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB
It provides output like follows
"Build 13"
master replica: My_PVOB#\My_PVOB
owner: Admin
group: ABC
stream:Components_Integration#\My_PVOB
component: Baselines#\My_PVOB
label status: No Versions to Label
change sets:
promotion level: INITIAL
depends on:
Baseline_2.1.0.13.8206#\My_PVOB (Comp1#\My_PVOB)
Baseline_2.1.0.13.433#\My_PVOB (Comp2#\My_PVOB)
Baseline_2.1.0.13.423#\My_PVOB (Comp3#\My_PVOB)
Baseline_2.1.0.13.3763#\My_PVOB (Comp4#\My_PVOB)
Actually i want to get contents only below depends on: ( Want to get Just following contents)
Baseline_2.1.0.13.8206#\My_PVOB (Comp1#\My_PVOB)
Baseline_2.1.0.13.433#\My_PVOB (Comp2#\My_PVOB)
Baseline_2.1.0.13.423#\My_PVOB (Comp3#\My_PVOB)
Baseline_2.1.0.13.3763#\My_PVOB (Comp4#\My_PVOB)
How to omit the remaining information?
From the fmt_ccase man page:
%[depends_on]Cp
(UCM baselines) The baselines that the composite baseline directly depends on
So for a composite baseline:
cleartool descr -fmt "%[depends_on]Cp" baseline:aBaseline#\apvob
could do the trick, except it will print only the dependent baselines on one line, each name separated by space, and without their associated component name.
So you need to parse that output, and for each baseline name, do a:
cleartool descr -fmt "%[component]Xp" baseline:aBaseline#\apvob
(Or, if your naming convention for baselines allows for it, a simple:
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB | grep Baseline_
would be easier!)
Actually, the OP samselvaprabu took the last proposition to grep what he needed from the initial output. His grep is better than my proposal, because it doesn't depend on the Baseline naming convention, but on the PVob name of said baselines:
I am using windows so your last(simple) command gave me the idea.
Following command works in Dos
cleartool describe -l baseline:Baseline_2.1.0.13#\My_PVOB | find "#\My_PVOB)"
Read "fmt_ccase" manual, you'll find it over there:
cleartool man fmt_ccase
I could not find the proper command to apply a label to files which are in my current view. I have tried the following command:
cleartool mklabel -r TEST_LABEL /vob/test/a
However, the problem is that this command will apply the "Test_Label" label to every files in the "vob/test/a" directories regardless of whether the files are in my current view.
Is there any command to apply label only to the files listed in my current view?
cleartool mklabel -r(ecurse) LABEL_NAME <directory name>
This command will apply LABEL_NAME to all files in folder and below of your view, you can just go to that directory,then type following command to create and apply label
> cd /vob/test/a
> cleartool mklbtype –nc TEST_LABEL
> cleartool mklabel -r TEST_LABEL .
The mklabel documentation state states, as to what version is labeled:
Processes the entire subtree of each pname that is a directory element (including pname itself). VOB symbolic links are not traversed during the recursive descent into the subtree.
One example mentions:
Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
Now, if you want to be really sure of the versions actually labelled, one solution is to use a find command, combined with your mklabel:
cleartool find . -cview -exec "cleartool mklabel TEST_LABEL \"%CLEARCASE_XPN%\""
If you had already that label applied to incorrect version and want to move it:
cleartool find . -cview -exec "cleartool mklabel -replace TEST_LABEL \"%CLEARCASE_XPN%\""
That way, you can first list the versions involved:
cleartool find . -cview -print
And then, if you agree with the output, apply the mklabel through the -exec directive.
The OP user1096966 reports making it work with a cleartool ls, to be sure to select only element visible in the current view:
cleartool ls -r -vis
The is no '-exec' directive, so a pipe might be involved, as in (not tested, but you get the idea):
cleartool ls -r -vis -s -nxn | xargs cleartool mklabel -replace TEST_LABEL
The doco is really clear about what is being labelled, in fact the first example shown in doco states that exactly...current view objects are labelled by default & currently selected versions (i.e. if in your view then label it, else not.)
....extract below from doco below (note: context and command and that label-type-selector pname is the last parameter...left blank below because resident in working dir)...
Example:
•Create a label type named REL6. Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
cmd-context> mklbtype –nc REL6
Regards
Jim2
I know one awkward solution for this taks will be :
first use ct ls to get the entire version info of the file
and pipe the version info to a parsing script to actually get the labels of the file .
But I guess ClearCase should have a "build in" solution for this task without support from any external scripts.
Please help me if you happen to know a "build in" solution for the task.
Thanks in advance.
fmt_ccase contains all the format-string for various ClearCase elements.
For a version of a file, you can:
cleartool descr -fmt "%l\n" /path/to/a/version
%l
Labels: For versions, all attached labels; the null string otherwise.
Labels are output as a comma-separated list, enclosed in parentheses.
A <SPACE> character follows each comma.
Variants:
%Cl
Max labels: Specify the maximum number of labels to display with the max-field-width parameter (see Specifying field width).
If there are more labels, "..." is appended to the output.
If no max-field-width is specified, the maximum default value is 3.
%Nl
No commas: Suppress the parentheses and commas in label list output;
separate labels with spaces only.
So the result can be:
Labels: (Rel3.1C, Rel3.1D, Rel3.1E)
Labels without commas or parens: Rel3.1C Rel3.1D Rel3.1E
In both case, you still need to parse the result, but at least the output can contain only the labels, as in:
Rel3.1C Rel3.1D Rel3.1E
onaclov2000 adds (from the comments):
The only problem with this is that you are grabbing the label on the specific version of the file.
Given that branches etc can exist, we'll need to be able to get ALL labels on a file.
If you use version tree graphical and select tools -> "locate" you can see ALL the labels attached to that file.
Is there a common command in cleartool that will return the results of "locate", or "contents"?
The lsvtree (graphical version tree) does display the labels of all the versions of the element currently seen by the view when you click "Label Name"
That being said, there does not seem to be a "built-in" solution and some parsing is involved:
For instance (which is a bit shorter than the OP version but still based on a cleartool ls):
ct ls -l addon.xml##|grep version|gawk "{gsub(/^version.*##\\\\/,\"\",$0) ; gsub(/ \ [.*/,\"\",$0); print $0}"
(GnuWin32 syntax)
or, only with a dynamic view:
cd m:/myView/path/to/addon.xml##
# list all files, not directories: the files are the labels
dir /B /A-D
The IBM article "Additional examples of the cleartool find command" is a great source for find query.
To expand on the "lsvtree" bit mentioned by VonC in his answer, you have:
To find all elements with any label:
Windows:
cleartool find . -type f -exec "cleartool lsvtree -a %CLEARCASE_PN%" | findstr
"("
./hello.c##/main/1 (LABEL100, LABEL99, LABEL98, LABEL97)
./foo.xml##/main/BR1/1 (REL2)
./bar.o##/main/1 (REL1)
UNIX/Linux:
cleartool find . -type f -exec 'cleartool lsvtree -a $CLEARCASE_PN' | grep "("
./hello.c##/main/1 (LABEL100, LABEL99, LABEL98, LABEL97)
./foo.xml##/main/BR1/1 (REL2)
./bar.o##/main/1 (REL1)
That finds only labels for versions currently selected in the view, but you could reuse the lsvtree part to grep all versions of a file with labels.