Как правильно обновить функцию ветки из ствола?

Question

В книге SVN написано :

...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

Я считаю этот подход очень непрактичным в крупных разработках по нескольким причинам, в основном связанным с этапом реинтеграции.

1. В SVN v1.5 объединение выполняется rev-by-rev. Вишневый выбор областей для слияния заставил бы нас разрешить конфликты между стволами и ветвями дважды (один при слиянии ревизий соединительных линий с FB и еще раз при слиянии назад).
2. Размер репозитория: изменения в стволе могут быть значительными для большой базы кода, а копирование файлов различий (в отличие от копирования SVN) из ствола в другом месте может привести к значительным накладным расходам.

Вместо этого мы делаем то, что мы называем «повторным ветвлением». В этом случае, когда требуется значительная часть изменений транка, новая ветвь объекта открывается из текущего транка, и слияние всегда происходит вниз (ветви элемента -> ствол -> стабильные ветви). Это не соответствует рекомендациям SVN, и разработчики видят в этом дополнительную боль.

Как вы справляетесь с этой ситуацией?

Answer 1

В SVN v1.5 объединение выполняется rev-by-rev. Вишневое выделение областей для слияния заставит нас разрешить конфликты между стволами и ветвями дважды (один при объединении ревизий соединительных линий в FB и еще раз при объединении назад)

Тогда вы делаете что-то не так!

Посмотрим:

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

Как правило, если вы хотите, чтобы изменения были сделаны в 11-20, то лучше всего объединить 1-20 в fb и получить все там.

Затем, когда fb будет завершен, объедините 20-30, а затем скопируйте fb в транк (без слияния!).

Если вы решили объединить только r11: 20, хорошо, в конце вам нужно будет объединить r1: 10 и r20: 30 а затем скопировать fb в транк.

Нет способа объединить изменения дважды!

Я предполагаю, что вы, вероятно, делаете следующее:

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

Вы не можете сделать это, потому что вы бы слились 11:20 дважды. Вы должны всегда объединять код в только в одном направлении.

Правильный путь:

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

Редактировать

Итак, правильные шаги:

1. Создание ветви объектов (FB) из ствола (копирование ветви в функцию с помощью svn-copy)

   FB_0=trunk_0
   

2. Работа на ФБ.

   FB_1=FB_0 + change_a
   

3. Объединить все предстоящие изменения из транка в FB.

   trunk_1=trunk_0 + tr_change_a;
   FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a
   

4. Работа над FB

   FB_3 = FB_2 + change_b
   

5. Объединение всех предстоящих неотложенных изменений из транка в FB.

   trunk_2=trunk_1 + tr_change_n;
   FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b
   

6. На данный момент у нас есть ветвь функций, которая состоит из всех новых функций и все изменений в багажнике. Поэтому мы просто копируем разницу между двумя ветвями.

   trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b
   

   Теперь FB удален, так как в транке есть все необходимые изменения.

   Последний шаг выполняется:

   svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
   svn ci
   

   Или на обычном языке возьмите разницу между стволом и веткой и поместите их в ствол делая их эквивалентными.

Этот шаблон описан в http://svnbook.red -bean.com / ru / 1.4 / svn.branchmerge.commonuses.html # svn.branchmerge.commonuses.patterns.feature

Теперь, если это не работает для вас, тогда я не понимаю вопроса.

Редактировать2: Для SVN-1,5

При работе с svn-1.5 вы можете объединить гораздо проще:

Когда вы работаете над функциональной веткой, вы просто время от времени объединяете изменения:

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

Он выстроит ваш FB со всеми изменениями в транке. В конце FB вы запускаете эту процедуру еще раз, чтобы убедиться, что все в курсе. Вы идете в багажник и бежите

$ svn merge --reintegrate /path/to/fb
$ svn ci

В последнем случае не должно быть конфликтов, если вы работаете, как показано.

Answer 2

После исследования:

После многих сессий мозгового штурма на карте видения, обсуждений F2F, включая Артема, открытие книжного шкафа SVN и т. Д. - похоже, что это невозможно сделать. Функциональная ветвь совсем не похожа на рабочую копию. Единственный работающий способ обновить это - создать новую ветку, как описано выше.

Answer 3

Я думаю, что я должен взять дубинки для @Artyom здесь. Я тоже думаю, что если вам нужно

разрешить конфликты магистральных веток дважды

что-то не так. И я думаю, что аргумент / решение @Artyoms довольно основательный.

Я полагаю, что одна из незначительных вещей, которые @Artyom мог бы написать более ясным, заключается в том, что в конце, когда вы «копируете» fb в trunk, вы используете не svn copy, а svn merge (или svn merge --reintegrate) , Это может быть причиной того, что вы не можете найти шаблон «copy-merge» в Common Branching Patterns .

Поскольку я борюсь с пониманием того, что вы делаете до сих пор, я не уверен, что еще сказать.

Вот что я слышу:

Вместо этого мы делаем то, что мы называем «Повторно разветвленности». В этом случае, когда значительная часть изменений ствола необходимо, открывается новая ветка из текущего транка, ...

Теперь у вас есть новая ветвь (назовем ее b2), которая эквивалентна транку, верно? И , где - это "значительная часть изменений в магистрали"? Я предполагаю в фб?

... и объединение всегда вниз (характерные ветки -> ствол -> стабильные ветки).

Но поскольку вы только что создали b2 из транка, в транк нет ничего, не так ли? И вы не объединяете изменения из b2 в fb (как это было бы то же самое, что объединение магистрали в fb ...). Так как же «значительная часть изменений» попадает в fb? И как только они появятся, почему вы захотите объединить их обратно в магистраль (так как именно отсюда они и появились)?

На самом деле следующие ссылки раздел под названием «Отслеживание слияний вручную» и / или раздел под названием «Слияние всей ветви с другой» , предоставленный в документации SVN 1.4 (я знаю , вы не используете SVN 1.4, но я считаю, что это применимо в любом случае) в Common Branching Patterns может помочь прояснить некоторые вещи. Эти ссылки «отсутствуют» в документации 1.5 (возможно, из-за новой опции --reintegrate в merge).

Вы, кажется, действительно объединяете одни и те же изменения дважды, и я действительно думаю, что вы не должны (должны) делать это.

Answer 4

К сожалению, все упомянутое можно считать хаком. Обновление из ствола на ветке может привести к очень серьезным проблемам при возвращении его в ствол и открывает возможность для худшего из всех конфликтов, конфликтов дерева. Это потому, что каталоги не рассматриваются как граждане первого класса. Наилучший подход - использовать Mercurial с Расширение SVN как ваш стандартный клиент SVN. Это позволяет вам продолжать использовать SVN, одновременно используя возможности Mercurial для работы с папками.

Затем на стороне рабочей станции вы можете использовать ряд подходов, которые предоставляют множество функций, подходящих для многих ситуаций по сравнению с одним SVN. Вы можете использовать обычные исправления, очереди исправлений, обновление из локальной копии соединительной линии, не затрагивая общую соединительную линию, и различные другие подходы.

Этот подход работает вокруг всех нисходящих сторон SVN. Мне пришлось перейти на этот подход из-за похожих обстоятельств. Даже если вы не используете этот подход немедленно, вы должны хотя бы попробовать его как можно скорее.

Answer 5

Мы небольшая компания, поэтому я не знаю, будет ли наше решение применяться в вашей ситуации. То, что мы делаем, это слияние оборотов от магистрали до стабильной ветки. Мы можем сделать это двумя разными способами: - действительно нужно исправить, мы сливаемся сразу после совершения в багажник - Опасное исправление / изменение. Мы ждем несколько дней, пока изменение не будет подтверждено в транке, а затем объединяем

Благодаря этому постоянному объединению мы избегаем множества конфликтов.

Мои 2 цента.