ClearCase аннотирует, чтобы найти виновника, добавившего конкретный LOC

Я сейчас пишу скрипт, чтобы найти виновника, добавившего определенную строку кода в ClearCase. Я использую для этого команду annotate. cleartool annotate -all -fmt "%Ad %-8.8u %-100.150Vn | " -nheader -force Я использую -all, чтобы исследовать несвязанные уровни (не в той же линии происхождения). Но чую проблему. Если у меня есть 2 одинаковые строки кода в моем файле .c, какую из них выбрать? Поэтому, чтобы решить эту проблему, я подумал, что могу удалить все это и найти конкретную версию в той же линии происхождения. Затем посмотрите, какое слияние подходит к этой конкретной версии, и выполните еще одно annotate в этой версии.
Итак, мой вопрос: могу ли я сделать это, если в данный момент я не на этой версии?

cleartool annotate -all -fmt "%Ad %-8.8u %-100.150Vn | "  -nheader -force MEMManager.c@@\main\optimus_2_build\optimus_r10_integration_branch\12

Я в правильном направлении? Или есть лучшая команда, которую я могу использовать для достижения этой цели?


person djacob    schedule 05.12.2016    source источник


Ответы (2)


Я не могу сказать, как лучше всего справиться с этим, я могу рассказать о том, что я сделал в последний раз, когда мне пришлось иметь дело с вопросом «откуда взялось ЭТО изменение?» проблема.

Я прошел vtree обратно, используя аннотацию. Я аннотировал текущую версию с помощью -long (чтобы получить всю строку кода, потому что она была с большим отступом), и нашел измененную строку и откуда она взялась. Затем я перешел к этой версии, прокомментировал ее и обнаружил, что рассматриваемые строки взяты из еще одной версии (которая была объединена с этой «средней» версией). Вспеньте, смойте, повторите по мере необходимости.

Да, это было утомительно, но это было некоторое время назад... И мне почему-то не пришло в голову использовать -all.

Проблема «2 одинаковых изменения» может не иметь никакого влияния на работу. Но вот как эти «идентичные изменения» выглядят в простом исходнике hello.c:

##### 2016-12-05T09:19:55-05:00 Brian    \main\1                  |                         | #include <stdio.h>
#####                             .                               |                         | 
#####                             .                               |                         | int main(int argc, char** argv)
#####                             .                               |                         | {
##### 2016-12-05T09:23:38-05:00 Brian    \main\testbr\2           |                         |         // And here 
##### 2016-12-05T09:22:10-05:00 Brian    \main\3                  | UNRELATED               |         // And here 
##### 2016-12-05T09:19:55-05:00 Brian    \main\1                  |                         |         printf("Hello World!\n");
#####                             .                               |                         |         return 0;
##### 2016-12-05T09:21:31-05:00 Brian    \main\2                  | UNRELATED               |         // I felt like adding this here
##### 2016-12-05T09:21:02-05:00 Brian    \main\testbr\1           |                         |         // I felt like adding this here
##### 2016-12-05T09:19:55-05:00 Brian    \main\1                  |                         | }

«НЕСВЯЗАННЫЙ» означает, что он не произошел от текущей «линии происхождения», а также сообщает вам, где также произошло изменение. Это могло быть связано с тем, что одна из этих версий была объединена с несколькими ветками, или какая-то из них была очень продуктивной машинисткой.

person Brian Cowan    schedule 05.12.2016

cleartool annotate не определяет человека, изменившего строку кода, в (слишком) многих случаях. Просто подумайте о версии файла, созданной в результате слияния. cleartool annotate рассматривает эту версию как изменение, но это не настоящая версия! Настоящий на самом деле находится в другом потоке/ветке. Кроме того, может случиться так, что эта «настоящая» исходная версия не является реальной, а скорее местом назначения другого слияния! Это своего рода рекурсия.

Существует утилита ClearCase, GetRealChange, которая дает вам реальную версию для данной строки кода. Это быстро и поддерживает Windows и Linux. См. http://almtoolbox.com/va4vs.

person Alex Karnovsky    schedule 06.12.2016
comment
Иногда вам нужно пройтись по дереву назад, чтобы найти исходную версию, в которой произошло изменение, но это приведет вас туда. Getrealchange и Visual Annotate на самом деле являются внешними интерфейсами для аннотации cleartool... - person Brian Cowan; 06.12.2016
comment
GetRealChange на самом деле является независимым приложением, которое сравнивает содержимое файла одной ветки с другой, чтобы выяснить, откуда берется данная строка. - person Alex Karnovsky; 07.12.2016
comment
спасибо Алекс. На самом деле я хочу что-то, что я могу использовать в своем сценарии. Visual Annotate, похоже, ориентирован на графический интерфейс. - person djacob; 08.12.2016
comment
GetRealChange можно использовать как утилиту командной строки, которую можно встроить в свои сценарии: almtoolbox.com/blog/ - person Alex Karnovsky; 08.12.2016