SVN: нюансы в процессе слияния

Question

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

Магистраль управляется нашим менеджером проекта, и, за исключением чрезвычайных ситуаций, он единственный, кто реинтегрирует ветку обратно в магистраль.Операция реинтеграции в багажник также довольно ясна.У нас проблемы с тем, что делать в наших филиалах.(Примечание: мы используем TortoiseSVN вместо командной строки.)

Наши ветки разработчиков вышли из синхронизации, и, пытаясь разобраться в проблеме, я запутался в рабочем процессе иплюсы / минусы этих подходов:

1. симметричная повторная синхронизация между ветвью B и магистралью, выполнив следующие шаги:

   • объединение - реинтеграция из B в магистраль
   • объединить - реинтегрировать из магистрали обратно в B

2. асимметричная повторная синхронизация :

   • объединить --reintegrateиз B в транк
   • объединить - только для записи из транка в B (как это сделать в TortoiseSVN?)

3. реинтегрировать-и-рестарт :

   • слияние - реинтеграция из B в транк
   • удаление B
   • копирование транка в B для повторного запуска

4. односторонняя повторная синхронизация из магистрали в B:

   • объединение из магистрали в B
   • (повторять при необходимости, неили пора реинтегрировать в багажник.)

У нас все шло хорошо с вариантом № 1 (симметричная повторная синхронизация), и я действительно запутался, почему № 2 и № 3похоже, рекомендуемый подход.

Кто-нибудь может объяснить это?

Кроме того, каков правильный способ объединения ветвей B и C для обмена обновлениями без повторного слияния сбагажник первым? [Я задам отдельный вопрос]

Answer 1

Все, что вам нужно знать о том, что такое слияние Reintegrate, что оно делает и почему оно сделано таким образом:

http://blogs.collab.net/subversion/2008/07/subversion-merg/

сводка: все о ревизиях, которые синхронизируются'между ветвями, когда вы приходите к слиянию, вы ожидаете, что он правильно запомнит, какие ревизии вы хотите слить, а какие вы хотите исключить, поскольку уже слиты.Причина этого заключается в том, что иногда вы хотите включить те ревизии, где вам приходилось вручную разрешать конфликты - вы не хотите делать их снова;но обычно вы не хотите включать эти изменения.Таким образом, реинтеграция добавляет интеллектуальные возможности для управления этим, но за счет обычной гибкости - вы не можете реинтегрировать снова и снова, вы должны перезапустить после реинтеграции.Так что вариант №3 - единственный рекомендуемый вариант от парней из Subversion.

Answer 2

Я лично предпочитаю вариант 3. Всякий раз, когда вы делаете слияние, Subversion отслеживает, какие ревизии вы сливаете и откуда. Он делает это в суперсекретном (гласит: общеизвестно, но не редактируйте) свойстве svn:mergeinfo. То, как SVN хранит эту информацию о слиянии, становится сложным, и в зависимости от того, насколько ваши разработчики знакомы с процессом слияния, он может стать очень запутанным.

Слив B обратно в транк, транк получает svn:mergeinfo о том, что B между ревизиями X и Y теперь находится в транке. Затем, удаляя и создавая B только что из ствола, B теперь имеет всю необходимую историю и svn:mergeinfo (поскольку свойство svn:mergeinfo также было объединено) для журналов, чтобы знать, какие ревизии существуют в ветви (а какие нет). ). Это также помогает избежать конфликтов деревьев (которые никому не нравятся).

Вариант 2 может быть очень опасным. Компания, в которой я работал, полностью запретила слияния только с записями (это стало уголовно наказуемым преступлением), потому что в случае неправильного выполнения код может пропасть без вести. Тем не менее, теория заключается в том, что когда вы реинтегрируете B в транк, то в транке есть все B (и svn:mergeinfo для соответствия). Выполнение только записи в B предполагает , что B не будет использоваться для производственного кода (потому что он не будет иметь всех последних обновлений), а слияние только записи предоставит некоторую информацию для предотвращения конфликтов дерева (который, опять же, никто не любит).

Вариант 1 является хорошим промежуточным звеном. Ваша ветка B будет очень загромождена svn:mergeinfo, но, поскольку она суперсекретна (читается: обрабатывается в основном без проблем), если у вас нет огромного количества слияний, она должна хорошо служить вашим потребностям.