Perforce — генерировать патч после синхронизации

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

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

Я ценю, если вы можете указать мне, как автоматизировать с помощью скрипта. Шаги на p4v в порядке.

С уважением, Тоан Ле


person Toan Le    schedule 11.05.2011    source источник
comment
Что не так с использованием фактического механизма синхронизации? Пока вы знаете, в каком списке изменений вы находитесь, прежде чем синхронизироваться с новым списком изменений, синхронизация назад, если что-то пойдет не так, будет тривиальной задачей. Это похоже на изобретение велосипеда...   -  person Mike O'Connor    schedule 11.05.2011
comment
Я согласен с Майком, ты делаешь это более сложным, чем должно быть. Что вы подразумеваете под жесткими шагами отката? Это не может быть проще. Просто щелкните правой кнопкой мыши по представленному списку изменений и используйте элемент Back Out Submitted Changelist. Кроме того, почему вы отправляете код до проверки, если результат в порядке?   -  person raven    schedule 13.05.2011
comment
Упс, моей информации может быть недостаточно. Мои коллеги и я модифицируем один и тот же проект. К сожалению, администратор не настраивает личное пространство для ветвления. Поэтому все, что мы отправляем, будет находиться в основном потоке. Иногда синхронизация с другими приводит к сбою моего проекта, поэтому я думаю об использовании патча. Конечно, я могу поддерживать 2 рабочих места, но это пустая трата ресурсов. Что я хотел бы сделать, так это (1) создать патч из поддельной синхронизации (синхронизация p4 -n), мое рабочее пространство остается неизменным; (2) Я проверю и объединим вручную, чтобы убедиться, что результат не вылетит   -  person Toan Le    schedule 20.08.2011
comment
Я думал, что мой подход лучше, но оказалось, что плохая рабочая процедура вредит использованию хорошего инструмента. Согласитесь с Майком и Вороном не пытаться заново изобретать велосипед.   -  person Toan Le    schedule 27.09.2012


Ответы (1)


Как предположили Майк и Рейвен, это хорошие моменты.

Но также вы можете использовать стратегии ветвления — разбейте исходный код на 2 ветки. один для тестовой ветки и один для ветки выпуска. но здесь вам также придется работать над интеграцией/объединением. лучше всего было бы подтвердить вашу регистрацию принудительно с помощью любых инструментов CI (таких как hudson, curisecontrol) в рамках инкрементной сборки и запустить все необходимые тестовые случаи автоматически.

person Rajesh    schedule 28.07.2011
comment
Упс, моей информации может быть недостаточно. Ситуация такова, что команда (я принадлежу) модифицирует один и тот же проект. К сожалению, администратор не настраивает личное пространство для ветвления. Поэтому все, что мы отправляем, будет находиться в основном потоке. - person Toan Le; 20.08.2011
comment
наличие двух рабочих мест — хорошая идея. Я использовал его для тестирования выпуска и подтверждения, что все в порядке. - person Toan Le; 27.09.2012