Проблема: 2 проекта разделяли соединительные линии и обновляли некоторые из тех же файлов. Теперь должен быть выпущен один проект, поэтому перед началом проекта был создан новый филиал с контрольно-пропускного пункта.
У меня есть список только моих списков изменений из основной линии. Используя это, я могу сгенерировать список измененных файлов и diff-выход с помощью script с помощью команды "p4 описать #".
Можно ли переформатировать этот вывод и каким-то образом применить его к новой ветке?
Ответ на заголовок: "Возможно ли создать патч с помощью набора списков изменений?" Да.
p4 diff2 -u //path_to_your_sources/[email protected]_minus_1 //path_to_your_sources/[email protected] > /tmp/cln.patch.
Затем вы можете использовать /tmp/cln.patch в качестве входа в утилиту patch. Здесь "cln" - это номер списка внесенных изменений, для которого вы хотите создать патч для.
Я только что потратил два часа на борьбу с этим. Используя cygwin patch, мне пришлось проложить путь до тех пор, пока они не были распознаны.
В конце концов, магическое заклинание выглядело так (сломанные линии):
p4 diff2 -u //depot/foo/main/[email protected] //depot/foo/main/[email protected] |
sed '[email protected]//depot/@E:/Source/@g' |
sed '/^+++\|---/[email protected]/@\\@g' |
patch
То есть:
p4 diff2, чтобы получить унифицированный diff (-u) части хранилища между двумя версиями, которые меня волнуют. Второй список изменений - тот, который был до первого, который я хочу, иначе он не будет включен в diff.sed, чтобы изменить //depot/ на E:/Source/, где находится мое рабочее пространство.patch.Cygwin patch достаточно умен, чтобы проверять файлы из Perforce, но я не уверен, как заставить его делать это тихо. Он запрашивает Get file 'e:\Source\foo\whatever' from Perforce with lock?.
Это с p4 версия 2010.1, довольно недавняя установка Cygwin, работающая на PowerShell.
О, и после этого patch выписал окончание строк в стиле Unix, поэтому я использовал u2d, чтобы исправить их.
Perforce позволит вам переименовывать списки изменений для интеграции, что может быть проще, чем пытаться создать и применить патч. Perforce будет отслеживать, какие изменения вы интегрировали, где это может облегчить будущую интеграцию.
Предположим, что у вас был один багажник:
//depot/mycode/trunk
И вы проверили все свои изменения там. В какой-то момент вы разветвлялись стволом:
//depot/mycode/rel
И у вас есть список списков изменений на соединительной линии для слияния. Из спецификации клиента, которая отображает rel, интегрируйте каждый список изменений:
p4 integrate //depot/mycode/trunk/[email protected],1234 //depot/mycode/rel/...
где 1234 - номер списка изменений. Решайте после каждой интеграции. Вы также можете создавать, тестировать и совершать свои интеграции на разных контрольно-пропускных пунктах во время вашей интеграции, если вы можете определить хорошие моменты для этого. (Perforce может обрабатывать несколько интеграций за фиксацию, но если вы допустили ошибку, вам нужно будет вернуться к последней проверенной версии и повторить промежуточную интеграцию и разрешить.)