Итак, как дела?
Вы исправляете это в своей функциональной ветви и объединяете это с транком?
Если так:
Вы можете указать конкретные ревизии, которые вы хотите объединить в другую ветку. Например, если вы исправили ошибку в ревизии 1001 на ветке, вы хотите объединить только эту ревизию.
Вам также может понадобиться использовать флаг --reintegrate. Это используется при слиянии информации с родительской ветвью. Например, если ваша ветвь пришла из транка и вы объединяете информацию из ветки обратно в транк, вы используете опцию --reintegrate.
Если вы уже изменили код в транке и просто хотите записать слияние , вы можете использовать опцию --record-only. Это записывает, что изменение ветви было включено в транк, но фактически не выполняет слияние.
Или, было ли исправление на стволе, и вы хотите, чтобы это было в вашей ветви функций.
Если это так, вы хотите использовать обычный синтаксис слияния. На самом деле, вы должны объединяться рано и часто из магистрали в вашу ветку, поэтому у вас есть последний код в вашей функциональной ветке.
Опять же, если вы вручную применили патч к своей функциональной ветке, сделайте svn merge, но используйте опцию --record-only. Это позволяет Subversion пометить исправление как объединенное с веткой, но фактически не выполняет слияние. Это предотвращает попытки последующего слияния исправить ваше исправление.
Цель ветвления функции не в том, чтобы позволить вам войти в пещеру и программу, а в том, чтобы предотвратить влияние функции на сборку, пока функция находится в нестабильном состоянии. Я препятствую особенным веткам. Я хочу, чтобы разработчики были осторожны и вносили небольшие изменения, чтобы убедиться, что сборка все еще хороша. Я также хочу, чтобы их развитие было видно всей команде. Если вы создаете ветку из ствола, а затем сливаете код обратно в ствол, вы не увидите историю в ветке с svn log, если вы также не выполните --use-merge-history, и тогда журнал станет немного грязным.
Всякий раз, когда вы создаете ветку, вы сталкиваетесь с проблемами слияния, особенно если ветвь является сходящейся ветвью, подобной ветви функций. Разработчик должен постоянно сливать ствол в свою ветку, а затем пытаться объединить свою работу обратно в ствол. Хотя, теоретически, все слияние от ветви к стволу должно быть простой копией (если разработчик постоянно обновлял свою ветку), мы обычно заканчиваем множеством конфликтов слияния.
Единственный раз, когда я одобрю ветвь функции, это если работа над ней повлияет на способность кода быть построенным и протестированным. Даже добавление крупной новой функции редко делает это, если сделано аккуратно (как и должно быть). Ветвление функций обычно резервируется, когда код подвергается рефакторингу или переделывается центральная часть основы кода.