Хорошо, позвольте мне просто проверить сценарий - я полагаю, вы пытаетесь полностью изолировать разработчиков от транка, чтобы никто не связывался напрямую с транком. Я предполагаю, что ваша платформа автоматически создает эти ветви, и разработчики могут в какой-то момент сказать, что они закончили с веткой и вернули ее обратно. Итак, код следует циклу:
- Отделение
- Редактировать
- Подтвердить ответвление
- Повторно основать ветку от ствола
- Обновление ствола wc
- Реинтегрировать ветку в транк wc
- Передать транк wc
Я на самом деле все для этого, если ты так хочешь работать, отлично.
Я не могу придумать ни одной причины, по которой он сразу бы потерпел неудачу, но вы должны проверить следующие вещи:
- Ни один код не должен быть зарегистрирован без предварительного просмотра разработчиком.
- Ошибки всегда будут возникать в транке, и разработчикам может понадобиться способ взломать напрямую транк в какой-то момент.
- Даже если слияний нет, если разработчик не повторно подключился к последней магистрали, реинтеграция может привести к незначительным ошибкам.
Пункт 1 является наиболее важным. Это означает, что когда происходит реинтеграция, она должна быть фактически бездействующей. Если на вашем шаге 2.2 произойдет какое-либо слияние, я бы сказал, что вы должны выбросить коммит и заставить разработчика снова перебазироваться из транка. Даже если svn говорит, что слияние говорит о том, что оно прошло успешно и без конфликтов, вы просто не можете поверить, что сделали все правильно, чтобы выстрелить и забыть. Если вы собираетесь автоматизировать, гарантируйте, что то, что разработчик сделал, - это то, что объединяется, а не какой-нибудь автоматически сгенерированный гибрид.
Вы можете проверить, было ли слияние «чистым», просто взглянув на результат слияния - если какой-либо из файлов был «слит», то возникает проблема. Если они были только что обновлены, то все в порядке.
Пункт 3 интересен, но всегда является проблемой, даже при нормальной работе. В этом сценарии разработчик А сказал бы, что они закончили, повторно основали свою рабочую копию, а затем потратили некоторое время, проверяя, что все работает хорошо. В то же время разработчик B крадется в обновлении для ствола. Разработчик А решает, что все в порядке, и реинтегрирует. Тем не менее, изменения, внесенные разработчиком B, означают, что код не работает, даже если он не касается файлов, измененных dev A. Поскольку dev A был последним коммитом, их обвиняют.
Предполагается, что если бы dev A включил изменения в dev B, то он бы обнаружил проблему. Ваша платформа имеет возможность определить эту ситуацию (например, если svn-merginfo говорит, что есть изменения в стволе, которые могут быть переданы в ветку, это не актуально). Тем не менее, я бы также предостерег от создания вечного цикла слияния, когда в этом нет необходимости. Возможно, предупредите разработчиков о том, что с момента их пересмотра был сделан коммит, но в любом случае разрешите им продолжить.
Последнее замечание: я упоминал об использовании svn-mergeinfo выше. Вы не можете полагаться на это, полагая, что повторное объединение будет в порядке. Если вы это сделаете, между проверкой и выполнением слияния будет условие гонки - кто-то мог бы войти в это время. Вам все еще нужно проверить вывод команды фактического слияния, чтобы увидеть, что на самом деле произошло.
Также следует учитывать ситуацию, если несколько разработчиков пытаются реинтегрировать одновременно. Если вы каждый раз извлекаете свежую рабочую копию, у вас может быть сколько угодно, но фиксация может быть неудачной из-за старой ошибки типа «файл устарел». В этих ситуациях, опять-таки, реинтеграция не удастся, и вам нужно будет заставить разработчика заново основать свои ветви.
В целом мне это нравится. Там есть немало сложностей, но в конце концов, в этом и заключается суть такого рода системы - она имеет дело со сложными вещами, поэтому разработчикам это не нужно. Все, что им нужно сделать, это продолжать основывать свои ветви, пока система не позволит им успешно реинтегрироваться.