Поиск ClearCase для регистрации с определенным комментарием

Меня попросили предоставить информацию о регистрации, которую я сделал около 3 месяцев назад в ClearCase. Я знаю номер QC, который был включен в комментарий, но до сих пор совершенно не смог найти способ поиска ClearCase для проверки по комментарию.

Есть идеи?


person Mark Green    schedule 21.04.2009    source источник
comment
Я обновил свой ответ более эффективным запросом для поиска версии с определенным комментарием.   -  person VonC    schedule 23.04.2009


Ответы (2)


Вы просматривали это? В частности, раздел ниже.

Как найти элементы и версии с конкретными комментариями

Я хочу найти все элементы/версии с конкретными комментариями, такими как «Джейн изменила это 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

** Это направит вывод в файл, и вам придется искать в файле конкретные комментарии, которые вы ищете.

M:\my_base_view\my_base_vob>cleartool найти . -version !"lbtype(LABEL_NAME)" -exec "cleartool описать -long %CLEARCASE_PN%" >c:\output2.txt

Выглядит немного кропотливым процессом, к сожалению.

person Brian Agnew    schedule 21.04.2009
comment
Итак, почему за это проголосовали, когда это актуально и принято в качестве ответа? - person Brian Agnew; 21.04.2009
comment
К сожалению, извините: я понизил голос, но не объяснил, почему: ответ - слепая копия документации без каких-либо дополнительных предупреждений (длинный, не обнаруживает файл с именем rm, ...). слепой, потому что он включает в себя второй запрос, который не имеет ничего общего с комментариями... Короче: все, что мне не нравится видеть в ответе. Однако принцип, раскрытый в первой команде, верен и может быть базой ответа. Если Марку удалось решить с ним свою проблему, это все, что имеет значение. Идем дальше. - person VonC; 21.04.2009
comment
Ответ представляет собой ссылку на документацию с выделенными соответствующими битами для работы. Я думаю, что это немного другое. Как я отметил ниже, ваши модификации вышеизложенного верны и заслуживают внимания. - person Brian Agnew; 21.04.2009
comment
Я провел некоторое тестирование: lshistory для любого VOB со средней и большой историей является вредным решением (слишком большой файл output.txt, слишком долгое время работы). Я обновил свой ответ (который больше не является дополнением, как вы выразились) для действительно эффективного ответа. - person VonC; 23.04.2009
comment
-1: история после находки не имеет смысла: делается два запроса там, где достаточно одного. - person pindare; 04.05.2009

Брайан Агнью находится справа отслеживать, но слово предостережения:

  • Я уверен, что вторая командная строка НЕ ​​нужна (cleartool find . -version !"lbtype(LABEL_NAME)"...)
  • 'cleartool find -all' полезен, если вы считаете, что ваш файл мог быть перемещен, но для большого VOB этот процесс может быть очень долгим.
  • без опции «-nvis» он не найдет файл, если он был «rmnamed» (удален)
  • использование 'lshistory -minor' - это полное безумие: для vob с историей в несколько месяцев или лет это просто займет слишком много времени. Для каждого найденного элемента будет отображаться ВСЯ история для всех версий этого элемента без какой-либо возможности уточнить этот набор отображаемых версий. Это решение просто не масштабируется.
    Это и -minorопция команды 'lshistory' не приносят никакой пользы для решения проблемы: она будет отображать только одну и ту же версию, несколько раз только из-за внутренних комментариев, таких как 'Attached hyperlink "Change@13707xx@\my_pvob'' или 'Attached hyperlink "Merge@xxxx@\my_vob"'

Вам нужно уточнить свой запрос с помощью:

  • тип требуемого элемента (если это файл: -type f)
  • например, дата "created_since(30-Jan)&&!created_since(28-Feb))" ограничит диапазон дат для рассмотрения
  • Пользователь

Я хотел бы использовать:

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

Это будет искать только те файлы, которые я зарегистрировал за определенный период времени, что позволяет иметь меньший набор версий для проверки.

Обратите внимание, что я использую 'descr' (команда describe), которая предназначена только для текущей версии (а не для отображения всей истории элемента, как это делает 'lshistory').

Если ваш файл был переименован, снова запустите ту же команду с параметром «-nvis» (она найдет только элементы вместе с их ветвями и версиями, которые не видны (не имеют стандартного пути) в представлении.

Предупреждение: если вы укажете дату «до» с днем ​​​​«в будущем» (например, «&&!created_since(28-Apr)}», тогда как мы еще не 28 апреля), всегда будет выбрано 0 версий (!?).
Это не имеет отношения к вашей проблеме, но если вы по ошибке введете «неверную дату до», это может создать ложное впечатление, что нет версии для поиска, хотя на самом деле версии есть.

person VonC    schedule 21.04.2009
comment
да. Я думаю, что вышеизложенное является хорошим дополнением. Пример в примечаниях IBM не связан с тем, кто сделал первоначальную регистрацию, поэтому вы можете оптимизировать его дальше. - person Brian Agnew; 21.04.2009