Мой вопрос: при объединении в соответствии с процедурой, приведенной ниже, является ли последний шаг процедуры "складывания ветви обратно в магистраль" правильным способом сделать это в сценарии передового опыта?
Я использую SVN уже много лет.В моих личных проектах я всегда счастливо хакнул на ствол, не задумываясь, и наличие версии в линейной линейной форме долгое время было близко к идеальному.Просто и эффективно.Все было блаженно, до того дня, когда я хотел получить больший контроль над сторонними библиотеками .
Сегодня я работаю над проектом, который, как мне кажется, перерос подход «взломать прямо из транка».У меня есть несколько сторонних библиотек, некоторые из которых меняются еженедельно, и мне действительно нужен больший контроль над тем, что происходит. Мне нужна возможность просматривать конкретные наборы изменений между сторонней версией lib и отслеживать изменения, которые я внес в конкретные библиотеки.Я видел, как несколько раз кодовая база становилась очень запутанной, и ее трудно вернуть в работоспособное состояние с неопытным мастером сборки, я не могу позволить себе время, чтобы ошибиться здесь.
Итак, я посмотрел ветвление поставщика, прочитал несколько статей здесь и там.У меня есть отличная книга «Контроль версий с Subversion», но примеры, которые я вижу, иногда противоречивы в своем подходе, и я хотел бы понять смысл «ветвления».Я собирался следовать подходу , представленному на этом посту Эваном Уивером .
Я изложил нижеприведенную процедуру, моя проблема в последнем разделе «Складывание ветви в ствол».Кажется, мастера сборки, с которыми я работал в прошлом, обычно «сливали» наборы изменений веток в транк, и я не думаю, что ветви были даже удалены.Это правильный подход?
Создание ветви
1 - Запишите текущую версию заголовка:
svn info svn://server.com/svn/repository/trunk | grep Revision
2 - Создайте чистую, удаленную копию магистрали впапка веток.Назовите это как-нибудь.Мы назовем его your_branch, заменив HEAD_REVISION на номер ревизии, который вы отметили на шаге 1.:
svn cp svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch \
-m "Branching from trunk to your_branch at HEAD_REVISION"
3 - переключите вашу локальную проверку, чтобы указать на новую ветку (это не перезапишет ваши изменения):
svn switch --relocate \
svn://server.com/svn/repository/trunk \
svn://server.com/svn/repository/branches/your_branch
4 - Убедитесь, что ваша локальная проверка определенно теперь your_branch, и что вы можете обновить ok:
svn info | grep URL
svn up
5 - Применить новые изменения при необходимости.
Обновление ветки
Вы уже некоторое время разрабатываете на your_branch, как и другие люди в транке, и теперь вы должны добавить их изменения в your_branch.
1 - Во-первых, обновите оформление ветки и подтвердите все оставшиеся изменения.
2 - Найдите в журнале Subversion журнал, чтобы узнать, под каким номером ревизии вы в последний раз объединили изменения (или когда была сделана оригинальная ветка, еслиты никогда не сливался).Это важно для успешного слияния:
svn log --limit 500 | grep -B 3 your_branch
3 - Также обратите внимание на текущую ревизию головы:
svn info svn://server.com/svn/repository/trunk | grep Revision
4 - Слияние разницы последней слитой ревизии на стволе иревизия заголовка на транке в рабочую копию your_branch, заменяя LAST_MERGED_REVISION номером ревизии, отмеченным на шаге 2, и HEAD_REVISION с номером ревизии, отмеченным на шаге 3:
svn merge -r LAST_MERGED_REVISION:HEAD_REVISION \
svn://server.com/svn/repository/trunk .
5.a - Поиск ошибок в выходных данных,Можно ли найти все файлы?Были ли удалены те вещи, которые не должны были быть?Возможно, ты сделал это неправильно.Если вам нужно вернуться, запустите svn revert -R
5.b - Если в 5.a все выглядит нормально, проверьте наличие конфликтов, разрешите все обнаруженные конфликты:
svn status | egrep '^C|^.C'
6 -Зафиксируйте слияние, заменив COMMAND точным содержимым команды из шага 4.:
svn ci -m "Merged changes from trunk to your_branch: COMMAND"
Сложите ветвь обратно в транк
Эй, your_branch готово.Теперь он должен стать транком.
1 - Сначала выполните каждый шаг в предыдущем разделе («обновление ветви»), чтобы your_branch синхронизировался с любыми последними изменениями в транке.
2 - Полностью удалить сундук:
svn del svn://server.com/svn/repository/trunk
3 - Переместить ваш филиал на старое место сундука:
svn mv svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
4 - Reнайдите свою рабочую копию обратно в транк:
svn switch --relocate \
svn://server.com/svn/repository/branches/your_branch \
svn://server.com/svn/repository/trunk
Готово!
Пожалуйста, любые советы, комментарии или отзывы об этой процедуре приветствуются.