Perforce: найти список изменений источника для ветки

Укороченная версия:

После разветвления в P4, как я могу узнать "исходный" список изменений ветки?

Длинная версия:

Допустим, у меня есть основная ветка моего проекта по адресу

//project/main/...

Последний представленный здесь список изменений - @ 123, когда я решил создать ветку для выпуска 1.0 в

//project/1.0/...

Из P4V создается новый список изменений (скажем, @ 130), обрабатывается и отправляется.

В интерфейсе командной строки это будет выглядеть примерно так:

p4 integrate -c 123 -o //project/main/... //project/1.0/...
p4 submit

Позже я просматриваю списки изменений в разделе //project/1.0 и вижу список изменений @ 130, содержащий множество разветвленных файлов. Как я могу узнать список изменений № что это изначально ответвление от (то есть @ 123)?


person Cristian Diaconescu    schedule 03.11.2010    source источник
comment
Nitpick: команда CLI - p4 integrate //project/main/... //project/1.0/.... (-c 123 завершится ошибкой, потому что -c указывает ожидающий список изменений. В вашем примере 123 - это уже отправленный список изменений.)   -  person Jon-Eric    schedule 09.11.2010
comment
@Jon Ты работаешь в Perforce? Так получилось, что вчера я связался с их службой поддержки, и они указали на ту же ошибку, что и я :). Время было идеальным. Кстати, я предлагаю использовать p4 filelog в основном с теми же параметрами, которые вы используете для p4 changes, но я думаю, что ваше решение дает более четкие результаты (т.е. я могу просто взглянуть на список изменений, который мне нужен, в отличие от версии журнала, которая намного более подробна ).   -  person Cristian Diaconescu    schedule 10.11.2010
comment
Я знаю, что изначально дал плохой ответ, но я полностью его пересмотрел и пошел совершенно по-другому. Я просто хотел вас уведомить; Я не уверен, уведомлены ли спрашивающие о пересмотренных ответах или нет.   -  person Chance    schedule 10.11.2010


Ответы (7)


p4 changes отобразит список отправленных списков изменений, при желании отфильтрованных по определенному пути.

p4 changes //project/main/...
Change 123 ... 'Very last change.'
Change 122 ... 'Next-to-last change.'
Change 100 ... 'Only two changes to go...'
...

В этом нет ничего удивительного, но, как вы обнаружили, p4 changes менее полезен, когда вы объединяете все эти изменения в одно изменение:

p4 changes //project/1.0/...
Change 130 ... 'Integrated everything from main.'

Хитрость заключается в использовании параметра -i, который включает все списки изменений, интегрированные в указанные файлы.

p4 changes -i //project/1.0/...
Change 130 ... 'Integrated everything from main.'
Change 123 ... 'Very last change.'
Change 122 ... 'Next-to-last change.'
Change 100 ... 'Only two changes to go...'
...

Чтобы получить именно то, что вы хотите (123), вам необходимо написать сценарий, который фильтрует вывод из p4 changes -i //project/1.0/..., чтобы удалить любые изменения, перечисленные в p4 changes //project/1.0/... (а затем принять самое последнее оставшееся изменение).

(Во время исследования я часто также нахожу полезной параметр -m max. Он ограничивает изменения до «максимального» значения самого последнего. Это помогает вашему выводу не перетекать за пределы экрана при большом количестве изменений.)

person Jon-Eric    schedule 09.11.2010
comment
Но могу ли я гарантировать, что самое последнее изменение в p4 changes -i, которого нет в p4 changes, будет родительским для данного набора изменений? Я могу объединить набор изменений 123 в ветвь X, а затем после этого объединить набор изменений 20. Итак, как я могу напрямую найти родителя данного набора изменений? - person Alexander Bird; 07.11.2012
comment
@AlexanderBird, нет, я не думаю, что это решение работает при объединении изменений, которые произошли до изменений, которые уже были объединены. - person Jon-Eric; 14.11.2012
comment
Не очень полезно для больших кодовых баз. Too many rows scanned (over 9000000); see 'p4 help maxscanrows'. - person Calmarius; 19.03.2013

Я не знаю ни одной простой команды, которая выполняет то, что вы хотели бы сделать. Если вы хотите немного написать сценарий и команда не должна выполняться быстро, вы могли бы попробовать написать что-то вроде следующего для всех разветвленных файлов:

  1. # P2 #
    # P3 #
  2. # P4 #
    # P5 #
  3. Повторите для всех файлов в ветке и выберите самое высокое изменение № (headChange выше), которое должно быть последним изменением, отправленным родительскому объекту перед ветвлением для этого конкретного файла. Вы можете получить полный список всех разветвленных файлов, например, "p4 файлы //project/1.0/...#1".

(или, возможно, воспользуйтесь более легким выходом и обратитесь в службу поддержки Perforce)

person rjnilsson    schedule 04.11.2010

Поскольку ни один из ответов до сих пор не содержит кода для поиска исходного или корневого списка изменений ветки, я подумал, что предоставлю однострочник для этого. Этот подход основан на предложении @Cwan и распечатывает «родительский» список изменений, из которого была создана ветка. Аргумент FIRST_BRANCH_CL необходимо заменить списком изменений для создания ветки (т. Е. Первым списком изменений, отправленным в новую ветку). В качестве конкретного примера, заменив FIRST_BRANCH_CL на 130 из исходного вопроса, этот однострочный запрос выведет 123.

p4 describe -s FIRST_BRANCH_CL | perl -lne 'if(/^\.\.\. (.+#[0-9]+) .+$/) {print quotemeta $1}' | xargs p4 filelog -m1 | perl -lne 'if(/^\.\.\. \.\.\. branch from (.+#[0-9]+)/) {print quotemeta $1}' | xargs p4 fstat | perl -lne 'if(/^\.\.\. headChange (\d+)/) {$MaxCL=$1 if($1 > $MaxCL)} END {print $MaxCL}'
person troydj    schedule 16.07.2014
comment
Эй, похоже, это действительно работает! Я попробовал это в одной из наших веток, после того как сначала нашел ту же информацию, используя ручные шаги, описанные Джон-Эриком. Однако на то, чтобы бежать, нужно время. - person fencekicker; 16.06.2016
comment
Хороший, но я думаю, было бы здорово, если бы вы объяснили причину своего единственного лайнера. - person Kostas; 13.02.2017

Краткий ответ:

Использование Revision Graph в P4V - это шаг назад во времени и изучение истории интеграции. Видео на веб-сайте Perforce.

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

Длинный ответ:

... [Удаленный]

ОБНОВЛЕНИЕ: поскольку график изменений, по-видимому, неосуществим, вы, возможно, можете решить эту проблему с помощью процесса / политики, то есть, когда вы выполняете интеграцию, добавьте примечание в описание «Branch @ CL 123». Мы сами использовали этот подход при интеграции от магистрали к линиям выпуска.

person Dennis    schedule 04.11.2010
comment
К сожалению, наличие пары сотен файлов в каждой ветке делает невозможным подход «Просмотр графика ревизий». Поскольку команда, которая создает интеграцию, указывает исходный список изменений, я надеялся, что информация будет где-то сохранена, и я просто не знаю, где искать. Я предполагаю, что всегда существует нечеткий подход к проверке временных меток списков изменений в исходной ветке и поиску ближайшего к метке времени интеграции. - person Cristian Diaconescu; 04.11.2010
comment
Что касается обновления вашего ответа: мы действительно используем нечто подобное в нашем процессе; Я просто надеялся, что существует автоматический способ, и никто не стал его искать. - person Cristian Diaconescu; 09.11.2010

Если вы используете вкладку истории в p4v, она покажет вам все списки изменений, отправленные для ветки, поэтому посмотрите на это, чтобы

//project/1.0/...

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

Я посмотрю, смогу ли я вернуться с командами p4, чтобы сделать то же самое.

person Toby Allen    schedule 07.11.2010

Обновленный ответ: Думаю, это сработает. Попробуй это:

p4 interchanges from_branch  to_branch

Это покажет неинтегрированные изменения из вашей основной ветки в ветку выпуска. Я считаю, что вы можете использовать верхний номер списка изменений минус 1, чтобы найти свой исходный список изменений. interchanges - недокументированная функция интерфейса командной строки Perforce. Чтобы узнать больше, введите p4 help interchanges, чтобы узнать больше об этой команде.

Опять же, я думаю, что это сработает. Могут быть некоторые особые случаи, когда этого не произойдет, но это мое лучшее предположение для сложной и важной проблемы.

person Chance    schedule 04.11.2010
comment
Немного нюанс: если ветка была выполнена, когда изменение 120 было последним отправленным изменением в // project / main, а представленное изменение интеграции получило номер 129, тогда main @ 120 и 1.1@129 должны быть идентичны для большинства практических целей, но помните, что вы можете отредактировать цель перед отправкой, повысив цель для добавления с помощью p4 edit, а затем изменив содержимое файла. - person rjnilsson; 04.11.2010
comment
После интеграции мне может потребоваться выбрать списки изменений для обратного переноса с основного на 1.0. Мне нужна начальная интеграция CL из / main (@ 123 в моем примере), чтобы точно видеть, что было добавлено в main после точки интеграции. (Вероятно, что в / main могут быть изменения между @ 123 и @ 130) - person Cristian Diaconescu; 09.11.2010
comment
Я только что понял. Вы переходите от предыдущего списка изменений, не обязательно (обязательно) к самому последнему. - person Chance; 09.11.2010
comment
Это странно, я обновил свой вопрос, чтобы признать свою ошибку, и получил -1. - person Chance; 09.11.2010
comment
-1 Даже, если вы всегда интегрируете самый последний список изменений из основного, этот подход все равно не всегда работает. Представьте себе случай, когда кто-то отправляет изменение в main после запуска integrate, но до submit. Делать предположения на основе номеров в списках изменений почти всегда слишком небрежно. - person Jon-Eric; 09.11.2010
comment
@ Джон-Эрик, в принципе ты прав. Я подумал, что если кто-то отправил список изменений во время интеграции, то вы на самом деле не отправляете самый последний список изменений, но ваша точка зрения все еще остается в силе. Я пытался извлечь максимальную пользу из плохого ответа, который изначально дал, поскольку неправильно прочитал вопрос. Но да, я понимаю вашу точку зрения, вы не можете предполагать, что две ветви будут одинаковыми для определенного номера списка изменений. - person Chance; 09.11.2010

"p4 интегрированный" у меня работал. Ищите "копировать из" в описании.

person Jesper    schedule 21.01.2017