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?
Brian Agnew is on the right track, but a word of caution:
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-nvis
' option, it won't find the file if it has been 'rmnamed' (removed)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.-minor
option 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:
-type f
)created_since(30-Jan)&&!created_since(28-Feb))
" for instance would limit the date range to considerI 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.