Subversion: объединение поддеревьев или отслеживание слияний

Question

Перенесено из В ветви компонента Subversion требуются изменения из другой ветви функции

У меня есть две ветви функций: «FeatureA» и «FeatureB». Функция FeatureA завершена, но не объединена с транком, поскольку не подтверждено, должна ли она быть в следующем выпуске.

FeatureB находится в процессе, и оказывается, что требуется внести некоторые изменения в dbml , которые фактически были применены к FeatureA.

У меня есть несколько вариантов, один из которых - объединить только DBL и связанные файлы. Я знаю, что лучше всего объединять / обновлять / фиксировать и т. Д. Из корня рабочей копии, но какие проблемы это может вызвать, если я буду продолжать?

Answer 1

Вы можете объединить все ревизии из FeatureB с веткой FeatureA, которую вы хотите (хорошая идея отметить объединенные ревизии, поскольку subversion не сделает этого за вас - инструмент svnmerge.py сделает это, но я бы лучше вел запись себя). Затем отмените / удалите изменения, которые вам не нужны (например, как вы отметили в предыдущем вопросе, они являются частью изменений).

Я хотел сказать следующее: «Позже, во время слияния FeatureA и FeatureB с транком, не должно быть конфликтов, если отмененные вами изменения не будут зависеть от других изменений в ветви FeatureB». Но я не уверен, правда ли это. То есть, есть ли конфликт / двойное изменение, если есть общее изменение в FeatureA и FeatureB, когда эти изменения объединены в магистраль?

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

Одним из способов упрощения является использование флага в коде для включения или выключения FeatureA. Таким образом, FeatureA уже можно объединить с транком.

Answer 2

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

Answer 3

Я думаю, что вы получаете вопрос "поддерево mergeinfo". Эксперты говорят, что этого лучше избегать . Но производительность также является проблемой, так как выполнение слияния в корне большой ветви может занять много времени. Чтобы избежать проблем с производительностью, я выполнил слияние поддеревьев и могу подтвердить, что результирующее поддерево mergeinfo действительно вызывает некоторые проблемы. Поэтому вам следует избегать этого, когда это возможно.

Answer 4

Мне полезно помнить, что слияния в svn описываются тремя параметрами. Вы берете изменения, которые преобразуют rev X в rev Y, и применяете эти изменения к rev Z. Я думаю, что это противоречит тому, что вы сказали об использовании рабочей копии.

Таким образом, один из подходов состоит в том, чтобы найти изменения, внесенные в dbml в ветви Feature A (идентифицированные по начальной и конечной ревизии), и применить эти изменения к ветви Feature B.

Answer 5

Начиная с версии 1.6 Subversion отслеживает слияния, поэтому у вас больше не будет проблем.