SVN для чайников. Часть II

Работа с рабочей копией 

В предыдущей части мы рассмотрели основу основ SVN – репозиторий и научились с ним работать. Теперь рассмотрим операции с файлами проекта, с которыми разработчики сталкиваются чаще всего. Как мы помним наши программисты Вася и Петя создали локальный репозиторий. Импортировали туда  проект и создали рабочую копию проекта demo_project1. Оба наших программиста работают в своих собственных рабочих копиях.

Данный материал был опубликован в журнале "Компоненты и технологии"

Добавление файлов в рабочую копию.

Вася создает и работает над программой приветствия hello.py.Для этого, с помощью любимого редактора создает этот файл, добавляет в него рабочий код. Для того что бы поместить этот файл под контроль SVN, Вася использует команду Add
 

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

В результате выполнения команды файл помечается кандидатом на добавление к проекту и помечается соответствующей иконкой.

Для фиксации изменений Васе необходимо выполнить команду Commit.

Как правильный программист Вася не забывает оставлять комментарий.

После выполнения фиксации, иконка на файле показывает что файл находится под контролем SVN и в него не было внесено изменений.

Точно так же, только с файлом bye.py поступает и Петя. Теперь текущее состояние репозитория.

Для добавления директории с файлами, команда Add сначала используется для директории. При этом при добавлении Tortoise SVN предложит автоматически добавить файлы, которые находятся в директории, в список на добавление.

Синхронизация рабочей копии с репозиторием.

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

В результате у него в рабочей копии появляется файл Пети bye.py.

Который находится под контролем SVN.

При работе над проектами, особенно если работает команда разработчиков, регулярно выполняйте синхронизацию рабочей копии с репозиторием.

Изменение и откат файлов

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

Но поработав Петя понял что не все его изменения были правильные и он хочет убрать неправильные изменения из файла. Для этого он выполняет команду Diff над нужным файлом

Программа сравнения файлов показывает строки файла которые были изменены

Петя удаляет часть своих изменений, но тут понимает что все, внесенные им, изменения были ошибочны и хочет восстановить начальное состояние файла hello.py. Он делает Update, но состояние файла не изменяется.

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

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

Альтернативный, но не правильный, вариант отката изменения это удаление рабочей копии и новый Checkout.

Будьте крайне внимательны при откатах изменений, после отката восстановить сделанные модификации рабочей копии невозможно.

Переименование файлов

В процессе работы над проектом Вася и Петя решили что название файла документации readme.txt не отражает его содержание. И приняли решение о том, что файл нужно переименовать в documentation.txt. Вася выполняет команду Rename.

задает новое имя файла

В результате выполнения команды файл помечается иконкой добавления 

Дело в том, что в SVN команда Rename реализована с помощью механизма Delete-Add, но с автоматическим сохранением истории файла. Переименование изменяет файл в рабочей копии. Для того что бы зафиксировать это изменение в репозитории нужно выполнить Commit.
 

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

Перемещение файлов

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

Добавляет ее под контроль SVN.

Затем используя технологию Drag and Drop и правую кнопку мыши Петя выполняет перенос файла documentation.txt в папку doc.
 

В результате папка doc выглядит следующим образом

И после фиксации изменений проект в репозитории выглядит следующим образом

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

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

Разрешение конфликтов

В заключении работы Вася и Петя решили внести в файл документации documentation.txt информацию о себе. Вася зафиксировал изменения на долю секунды раньше чем Петя. Петя хочет зафиксировать свои изменения

Но в результате это сделать не удается

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

Петя получает конфликт файлов в своей рабочей копии. Для каждого конфликтного файла это выглядит следующим образом

В директории появились дополнительные 3 файла.

1. documentation.txt.mine — исходный файл Пети, изменения в котором он собирался зафиксировать в репозитории
2. documentation.txt.r13 – начальное состояние файла в репозитории, который модифицировал Петя в своей рабочей копии. Цифра означает номер ревизии файла
3. documentation.txt.r14 –текущее состояние файла в репозитории, которое содержит изменения сделанные Васей (поэтому номер ревизии и отличается).

Сам файл помечен иконкой конфликтного файла. У Пети есть два варианта как поступить:

1. неправильный вариант — откатить файл до исходного состояния, синхронизировать его с репозиторием и заново внести в него все изменения.
2. правильный вариант — разрешить конфликт средствами SVN. Дополнительные файлы, которые появились в директории создаются как раз для помощи в этом.

Для разрешения конфликта Петя с помощью команды Edit Conflicts

Cмотрит где именно возник конфликт

В TortoiseMerge видно 3 окна

1. Mine(мой) - в окне представлен файл Пети, который находится в рабочей копии.
2. Theirs(их) - в окне представлен файл Васи, который находится в репозитории. Этот файл не дает зафиксировать изменения Пете, так как файлы находятся в конфликте.
3. Merged(Слитый) - в окне представлен итоговый файл, который останется после слияния файлов mine и theirs и будет зафиксирован в репозитории.

Красные строки в окнах это и есть конфликтующие строки, видно что в файлах Васи и Пети эти строки разные. Оранжевые перечеркнутые строки это строки которые были в файле, при создании рабочей копии или последней синхронизации ее с репозиторием, но были удалены из файла.

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

Для устранения конфликта, Петя должен в окне Merged, сформировать итоговый файл. Сделать это он может как с помощью контекстного меню окна, в котором находится (доступно по нажатию правой кнопки мыши), так и набирая в окне Merged текст в конфликтующих строках.

Конфликт также можно просмотреть и устранить напрямую в файле documentation.txt

В файле видно 3 метки

1. <<<<<<< .mine — это изменения сделанные в Петей в рабочей копии
2. >>>>>>> .r16 — это изменения зафиксированные Васей
3. ======= - строка разделитель между конфликтующими строками в файле

Для разрешения конфликта в ручную, без применения средств автоматизации, нужно исправить код в файле, убрав из него все метки. Сделать это можно в любом текстовом редакторе. Но лучше для этого воспользоваться программой TortoiseMerge, которая вызывается командой Edit conflicts.

Петя решает использовать команду Edit conflicts и программу Tortoise Merge для слияния файлов.

Контекстное меню окна Merged предлагает варианты использования строк из Theirs и Mine окон, Петя выбирает команду команду Use text block from 'theirs' что бы вставить в итоговый файл строку из файла Васи.

И в ручную дописывает строку Васи в итоговом файле. Устранив все конфликты (в окне Merged больше нет строк красного цвета), Петя сохраняет итоговый файл и выходит из Tortoise Merge.

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

Все конфликт разрешен, Петя может фиксировать изменения в репозитории.

Конфликт возникает только в том случае, если два и более автора изменяют строки с одинаковыми номерами. Что и продемонстрировано в данном примере. В случае если изменяются разные строки конфликта не будет. Произойдет слияние двух файлов в один (т.е. результирующий файл будет содержать строки из обоих файлов). Надо помнить что если бинарный файл будет обрабатываться как текстовый (а SVN по умолчанию считает что все файлы текстовые), то естественно в результате будет нерабочий бинарник. Разделение бинарных и текстовых файлов рассмотрено ниже.

Использование конкретного номера ревизии файлов и папок.

Если для проекта потребуется для проверки или временно откатить некоторые папки и файлы назад, то не обязательно создавать новую рабочую копию со старым номером ревизии всех файлов. Достаточно откатить только те файлы которые нужны с помощью команды Update to revision

С помощью кнопки Show Log можно посмотреть список ревизий проекта

И выбрать нужную ревизию файлов или папок для работы

Блокировка папок и файлов

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

Не забываем оставлять комментарий ваших действий

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

Помните пока вы не разблокируете папки и файлы командой Release lock ваши коллеги не смогут их модифицировать и результат их труда может пропасть.