Переключение рабочей копии между ветками

Переключение между любыми ветвлениями выполняется командой Switch (рис. 65). В качестве параметра нужно указать путь к проекту в репозитории, на который нужно сделать переключение рабочей копии (рис. 66). При работе с командой Switch нужно помнить о следующем:

  1. Файлы, которые находятся под контролем SVN, при переключении ветки заменяются на соответствующие файлы из другой ветки. Если файл присутствует только в одной из веток, то соответственно он будет автоматически удаляться и появляться (это нормальная работа данной команды, нет повода для беспокойства).
  2. Изменения в рабочей копии обладают приоритетом перед состоянием файлов в репозитории. Если перед переключением вы их не зафиксировали, они останутся в рабочей копии. Если переключения происходят часто, то можно случайно зафиксировать эти изменения не в ту ветку разработки.

Рис. 65. Переключение рабочей копии на другую ветку разработки
Рис. 65. Переключение рабочей копии на другую ветку разработки

Рис. 66. Диалоговое окно выбора ветки на которую нужно переключиться
Рис. 66. Диалоговое окно выбора ветки на которую нужно переключиться

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

Слияние ветвлений

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

Эти действия в SVN выполняются с использованием команды Merge. Слить ветки можно только в рабочей копии одной из веток. При этом результат слияния будет в рабочей копии и в случае ошибок слияния этот результат можно отменить командой Revert.

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

При слиянии веток нужно помнить о следующем:

  1. При обычном слиянии файл не замещается другим файлом. Файл рассматривается как набор строк. Итоговый файл составляется из строк файлов, которые участвовали в процессе слияния. Поэтому если бинарный файл будет обрабатываться как текстовый, то результирующий файл будет не работоспособен.
  2. Переименование файла в SVN реализовано через механизм Copy/Delete поэтому новый файл логически не связан со старым (кроме общей истории). И после слияния веток в проекте будут оба файла. Избегайте необдуманного переименования файлов и учитывайте переименование при слияниях.

Рассмотрим процесс слияния demo_project1 и его ветки demo_branch. Положим, что Вася работает с веткой demo_branch, вносит изменения в файл hello.py и добавляет к проекту файл define.py. Петя в свою очередь работает в основной ветке разработки trunk и вносит изменения в файлы hello.py и bye.py. Перед слиянием состояние рабочих копий Васи и Пети следующее (рис. 67).

Вася и Петя фиксируют изменения в репозитории. Вася сообщает Пете, что закончил тестирование новых функций проекта, для которого он сделал ветку. Петя, который работает в основной ветке разработки, решает сделать слияние веток (рис. 68). SVNпредлагает 3 возможных сценария слияния веток (рис. 69). Для рассмотрения разницы этих сценариев положим что А это ветка-приемник, в рабочей копии которой делают слияние, В это ветка-источник с которой делают слияние. Сценарии слияния веток:

  1. Merge a range of revisions — этот сценарий работает следующим образом. SVN берет начальное и конечное состояние ветки В, вычисляет последовательные изменения в файлах этой ветки и последовательно применяет эти изменения на файлы ветки А. Если эти изменения вызовут конфликт, то его нужно будет разрешить, в противном случае произойдет слияние файлов.
  2. Reintegrate a branch — этот сценарий работает следующим образом. SVN берет текущее состояние веток А и В, вычисляет какие файлы нужно изменить для того что бы из А получить В и сравнивает эти файлы. Если в этих файлах возникает конфликт, то его нужно будет разрешить, в противном случае произойдет слияние файлов.
  3. Merge two different trees — самый простой и в то же время опасный сценарий слияния. Данный вид слияния работает следующим образом. SVN берет текущее состояние веток А и В, вычисляет какие файлы нужно изменить для того что бы из А получить В, делает эту замену в рабочей копии через механизм Delete/Copy. В этом случае не возникает никаких конфликтов, но если в А были какие либо изменения то они пропадут.

В нашем случае Петя выбирает второй вариант сценария и указывает делать слияние с веткой demo_branch (рис. 70). Результат работы команды Merge (рис. 71). Естественно при слиянии возникли конфликты, которые нужно разрешить (рис. 72).
После разрешения конфликтов Петя фиксирует изменения в репозитории и обязательно комментирует свои действия (рис. 73). Как разрешаются конфликты в SVN мы рассматривали в разделе работы с рабочей копией. Всё, слияние ветки demo_branch с основной веткой разработки выполнено.

 Рис. 67. Состояние рабочих копий веток Пети и Васи перед слиянием веток
Рис. 67. Состояние рабочих копий веток Пети и Васи перед слиянием веток

Рис. 68. Слияние веток в рабочей копии Пети
Рис. 68. Слияние веток в рабочей копии Пети

Рис. 69. Диалоговое окно выбора сценариев слияния веток
Рис. 69. Диалоговое окно выбора сценариев слияния веток

Рис. 70. Диалоговое окно выбора ветки источника для слияния
Рис. 70. Диалоговое окно выбора ветки источника для слияния

Рис. 71. Окно протокола слияния веток проекта
Рис. 71. Окно протокола слияния веток проекта

Рис. 72. Состояние рабочей копии Пети после слияния веток
Рис. 72. Состояние рабочей копии Пети после слияния веток

Рис. 73. Диалоговое окно для задания комментария при фиксации результат слияния меток.
Рис. 73. Диалоговое окно для задания комментария при фиксации результат слияния меток.