Я считаю, что то, что вы делали, копируя исправления ошибок из ствола в ветку релиза, иногда называется rebasing . Все перебазирование означает в этом случае, что вы берете ветку, которая обычно была основана, скажем, на ревизии r49 транка, и объединяете изменения, скажем, от r50-r57 транка, в ветку, так что после слов вы можете теперь рассматривать эту ветку как основанную на ревизии. багажник r57 вместо ревизии r49.
Проблема на практике заключается в том, что при объединении диапазона ревизий из ствола или любой другой базы в одну из его ветвей он не сбрасывает базовую ревизию, в которой была создана эта ветвь, а вместо этого оставляет нормальную Свойства mergeinfo как единственный способ узнать, что было объединено. Чтобы иметь возможность реинтегрировать изменения из ветви обратно в ее базу (например, ствол) без непреднамеренного воспроизведения изменений объединенной базы, скажем, с r50-r57 в моем предыдущем примере было бы объединить изменения из ветви в базу с помощью cherry. выбор определенных ревизий таким образом, что любые ревизии, вызванные перебазированием (слияние с базы в ветку), не включены.
К сожалению, кроме этого, разработчики Subversion должны реализовать способ автоматизации этого, чтобы только те ревизии, которые не содержат свойства mergeinfo, описывают слияние, которое содержит только ревизии между исходной базовой ревизией и целевой ревизией. базы (как правило, ГОЛОВА). Это усложняется тем, что слияния часто включают ручные изменения, которые передаются вместе с коммитом слияния на ветке, которая будет потеряна, а также происхождение любого данного объекта должно быть отслежено до его общего предка, чтобы это работало правильно на лестничных ветвях. Помимо этого, возможность, которая позволяла бы заменять ветку более новой копией базы или ствола со всеми предыдущими коммитами, повторно примененными как серия отдельных коммитов, также делала бы это возможным, и, тем не менее, неловкое поведение было бы больше похоже на настоящий перебаз .
Эти комментарии не являются окончательным ответом, но представляют мое понимание как давнего пользователя Subversion. Если у кого-то есть какие-либо другие пункты, которые можно добавить, или они могут выделить что-то, что может быть неверным в моих высказываниях, пожалуйста, дайте мне знать во что бы то ни стало, чтобы мы могли по-настоящему понять возможности и ограничения текущей реализации Subversion.
Обновление: Согласно документации Subversion представляется, что при использовании опции - реинтеграция эта Subversion должна иметь возможность правильно реинтегрировать работу, выполняемую в ветви, так, чтобы это имело в виду любые возможные объединения обновлений, которые могли быть сделаны для внесения базовых изменений в ветку. Конечно, технически это немного отличается от перебазирования, но я думаю, что оно достаточно схоже в использовании, что его можно назвать перебазированием. Основной вопрос теперь заключается в том, работает ли опция --reintegrate, когда изменения из базы были объединены в ствол в порядке вишни, а не объединены все от BASE + NEXT до HEAD.
Обновление: Похоже, что сбор вишни должен поддерживаться также при использовании svn merge - реинтегрировать для Subversion 1.5 и выше. Следование этим инструкциям должно позволить вам реинтегрироваться, не вызывая непреднамеренных конфликтов из-за ревизий изменений в базе изменений.
Для получения дополнительной информации прочитайте книгу Subversion в разделе, озаглавленном Синхронизация ветки .