Perforce: Найти исходный список изменений для ветки - PullRequest
13 голосов
/ 03 ноября 2010

Короткая версия:

После ветвления в P4, как я могу найти список изменений "источника" ветки?

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

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

//project/main/...

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

//project/1.0/...

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

Из CLI это будет выглядеть примерно так:

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

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

Ответы [ 7 ]

8 голосов
/ 09 ноября 2010

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. Этот ограничивает изменения до 'max' самой последней . Это помогает вашему выводу не течьза кадром, когда есть много изменений.)

1 голос
/ 16 июля 2014

Поскольку ни один из ответов до сих пор не содержит код для поиска исходного или корневого списка изменений ветви, я подумал, что для этого просто предоставлю однострочник.Этот подход основан на предложении @ 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}'
1 голос
/ 04 ноября 2010

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

  1. Найти исходный файл / версию для целевого файла.

    p4 filelog // project / 1.1 / foo.bar # 1 //project/1.1/foo.bar... # 1 изменение ветки 6416 в 2009/07/10 от foo @ bar (text) 'Release 1.1'... ... ветка от // project / main / foo.bar # 1, # 2

  2. Получитьсписок изменений, в который был отправлен исходный файл / ревизия.

    p4 fstat // project / main / foo.bar # 2 ... depotFile //project/main/foo.bar... headAction edit... headType text... headTime 1201771167... headRev 2... headChange 5353 ... headModTime 1201770971

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

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

0 голосов
/ 21 января 2017

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

0 голосов
/ 07 ноября 2010

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

//project/1.0/...

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

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

0 голосов
/ 04 ноября 2010

Обновленный ответ: Я думаю, что это будет работать. Попробуйте это:

p4 interchanges from_branch  to_branch

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

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

0 голосов
/ 04 ноября 2010

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

Использовать график изменений в P4V - шаг назад во времени и исследовать историю интеграции. Видео на сайте Perforce .

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

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

... [удалено]

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

...