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

Question

SVN book says:

...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

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

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

Answer 2

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

С этим непрерывным слиянием мы избегаем тонны конфликтов.

Мои 2 цента.

Answer 3

Из 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, хорошо, в конце концов вам нужно будет объединить г1: 10 и r20: 30 , а затем копия фб в ствол.

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

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

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.

   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/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature

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

Edit2: Для СВН-1,5

При работе с СВН-1.-Можно объединить намного проще:

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

разрешить конфликты переговорной ветви дважды

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

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

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

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

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

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

...и слияние равно всегда вниз (ветви функций -> багажник -> стабильные ветви).

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

На самом деле следующие ссылки the section called “Tracking Merges Manually" и/или the section called “Merging a Whole Branch to Another", приведенные в 1.4 документации SVN (я знаю, вы не используете SVN 1.4, но я считаю, что это относится так или иначе) под Common Branching Patterns может помочь прояснить некоторые вещи. Эти ссылки «отсутствуют» в документации 1.5 (вероятно, из-за новой опции --reintegrate в merge).

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