ClearCase аннотация, чтобы найти виновника, который добавил конкретный LOC

Question

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

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

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

Answer 1

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

Я пропустил 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     |       | } 

«неродственный» означает, что она Nto рода из нынешней «нисходящей линии», а также говорит Вам, где изменение тоже случается. Это может быть связано с тем, что одна из этих версий была объединена с несколькими ветвями, или некоторые из них были очень плодовитыми машинистами.

Answer 2

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

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