views:

1482

answers:

2

I've been asked to provide details of a checkin I did about 3 months ago into ClearCase. I know the QC number that was included in the comment but have so far failed utterly to find a way to search ClearCase for a checkin by comment.

Any ideas?

A: 

Have you looked at this ? Specifically the section below.

How to find elements and versions with specific comments

I want to find all elements/versions with specific comments like “Jane changed this on 11-26”

M:\my_base_view\my_base_vob>cleartool find -all -exec "cleartool lshistory -minor -fmt \"%n\t%c\n\" \"%CLEARCASE_XPN%\"" >c:\output.txt

**This will pipe the output to a file and you would have to grep the file for the specific comments you're looking for.

M:\my_base_view\my_base_vob>cleartool find . -version !"lbtype(LABEL_NAME)" -exec "cleartool describe -long %CLEARCASE_PN%" >c:\output2.txt

Looks a bit of a fiddly process, regrettably.

Brian Agnew
So *why* was this voted down, when it's relevant and accepted as an answer ?
Brian Agnew
Oops sorry: I did the downvote but did not explain why: the answer is a blind copy of the documentation without any additional warning (long, does not detect rmnamed file, ...). "blind" because it includes a second request which has nothing to do with comments... In short: everything I do not like to see in an answer. The principle exposed with the first command is sound though, and can be the *base* of an answer. If Mark managed to solve its issue with it, it is all that matter. Moving on.
VonC
The answer is a reference to the documentation, with relevant bits to work from highlighted. I think that's slightly different. As I noted below, your modifications to the above are correct and worth highlighting.
Brian Agnew
I did some testing: lshistory is, for any VOB with medium to large history, a "hurtful" solution (output.txt too large, time of operation too long). I have updated my answer (which is no longer an "addendum" as you put it) for an actual efficient answer.
VonC
That looks most worthwhile
Brian Agnew
-1: "lshistory" after a "find" makes no sense: two queries are made where one is enough.
TaintedLove
+3  A: 

Brian Agnew is on the right track, but a word of caution:

  • I am sure the second command line is NOT needed (cleartool find . -version !"lbtype(LABEL_NAME)"...)
  • 'cleartool find -all' is useful if you think that your file may have been moved, but on a big VOB, that process can be extra long
  • without the '-nvis' option, it won't find the file if it has been 'rmnamed' (removed)
  • using 'lshistory -minor' is sheer madness: on a vob with a few months or years of history, it will simply take too much time. For each element found, it would display the ALL history for all versions of that element, without any possibility to refine that set of versions displayed. That solution simply does not scale.
    That, and the -minoroption of the 'lshistory' command does not bring any value to the problem at hand: it would only display the same version several times, just because of internal comments like 'Attached hyperlink "Change@13707xx@\my_pvob"' or 'Attached hyperlink "Merge@xxxx@\my_vob"'

You need to refine your query with:

  • the type of element wanted (if it is a file: -type f)
  • the date "created_since(30-Jan)&&!created_since(28-Feb))" for instance would limit the date range to consider
  • the user

I would use:

M:\my_base_view\my_base_vob>
  cleartool find -all -type f -user myLogin -version "{created_since(30-Jan)&&!created_since(28-Feb)}" -exec "cleartool descr -fmt \"%n\t%c\n\" \"%CLEARCASE_XPN%\"" >c:\output.txt

That would only look for files checked-in by me for a certain date period, which is a way to have a smaller set of versions to examine.

Note that I use 'descr' (the describe command) which is only for the current version (and not for displaying the all history of an element like 'lshistory' does).

If your file has been rmnamed, run again the same command with the '-nvis' option (it would only find elements, along with their branches and versions, that are not visible (do not have a standard path name) in the view.

Warning: if you specify a "before" date with a day "in the future" (for instance: '&&!created_since(28-Apr)}' whereas we are not the 28th of April yet), it will always select 0 versions (!?).
This is not relevant for your issue, but if you enter a "wrong before date" by mistake, that can lead to the false impression that there is no version to find, where there actually are versions to be found.

VonC
Yes. I think the above is a good addendum. The example in the IBM notes doesn't concern itself with who made the original checkin, and so you can further optimise.
Brian Agnew