#perforce #sync #patch
#принудительно #синхронизация #исправление
Вопрос:
Я хотел бы зарезервировать «снимок» после принудительной синхронизации. Вместо того, чтобы применять синхронизацию ко всему дереву каталогов, я хотел бы сгенерировать файл исправления. Я применю вручную и проверю, удовлетворяет ли результат (после компиляции и запуска простых тестовых примеров). Я собираюсь выполнить синхронизацию официально, если результат будет в порядке. Если это NG, я могу вернуться к предыдущему «снимку» и продолжить без жестких шагов отката.
Я могу положиться на ‘patch’, поскольку он поддерживает ‘undo’. Указание принудительно не синхронизировать, а сгенерировать исправление, как я могу это сделать?
Я ценю, если вы можете подсказать мне, как автоматизировать с помощью скрипта. Шаги на p4v выполнены нормально.
С уважением, к вашему файлу
Комментарии:
1. Что не так с использованием фактического механизма синхронизации? До тех пор, пока вы знаете, в каком списке изменений вы находитесь, перед синхронизацией с новым списком изменений, синхронизировать обратно, если что-то пойдет не так, просто. Это похоже на изобретение колеса…
2. Я согласен с Майком, вы делаете это сложнее, чем это должно быть. Что вы подразумеваете под «жесткими шагами отката»? Это не может быть проще. Просто щелкните правой кнопкой мыши на отправленном списке изменений и используйте пункт «Отменить отправленный список изменений». Кроме того, почему вы отправляете код до того, как протестировали «если результат в порядке»?
3. Упс, моей информации может быть недостаточно. Мы с коллегами модифицируем один и тот же проект. К сожалению, администратор не настраивает личное пространство для выполнения ветвления. Следовательно, все, что мы отправляем, будет размещаться в основном потоке. Иногда синхронизация с другими приводит к сбою моего проекта, поэтому я думаю об использовании исправления. Конечно, я могу поддерживать 2 рабочих пространства, но это пустая трата ресурсов. Что я хотел бы сделать, так это (1) сгенерировать исправление из fake-sync (p4 sync -n), мое рабочее пространство остается неизмененным; (2) Я проверю и объединю вручную, чтобы убедиться, что результат не приведет к сбою
4. Я думал, что мой подход лучше, но оказывается, что плохая рабочая процедура вредит использованию хорошего инструмента. Согласен с Майком и Рэйвен не пытаться заново изобретать колесо.
Ответ №1:
Как и предполагали Майк и Рэйвен, это хорошие моменты.
Но также вы можете использовать стратегии ветвления — разбейте свой исходный код на 2 ветви. один для тестовой ветки и один для ветки выпуска. но здесь вам также придется поработать над интеграцией / слиянием. лучше всего было бы принудительно подтвердить вашу проверку с помощью любых инструментов CI (таких как hudson, curisecontrol) в рамках инкрементной сборки и автоматизированного запуска всех необходимых тестовых примеров.
Комментарии:
1. Упс, моей информации может быть недостаточно. Ситуация такова, что команда (я принадлежу) модифицирует тот же проект. К сожалению, администратор не настраивает личное пространство для выполнения ветвления. Следовательно, все, что мы отправляем, будет размещаться в основном потоке.
2. поддерживать два рабочих пространства — хорошая идея. Я использовал его для тестирования релиза и подтверждения, что все в порядке.