Основы систем управления версиями файлов на примере Subversion (SVN). Часть 2

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

Все статьи цикла:

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

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

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

Рис. 20. Установка метки файла для его помещения под контроль SVN

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

Рис. 21. Диалоговое окно проверки списка папок и файлов, добавляемых под контроль SVN

Рис. 22. Состояние рабочей копии перед фиксацией добавления файла в репозиторий SVN

Для фиксации изменений Васе необходимо выполнить команду Commit (рис. 23). Как правильный программист, Вася не забывает оставлять комментарий (рис. 24). После выполнения фиксации иконка на файле показывает, что файл находится под контролем SVN и в него не было внесено изменений (рис. 25). Точно так же, только с файлом bye.py, поступает и Петя. Теперь текущее состояние репо-зитория таково (рис. 26).

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

Рис. 24. Диалоговое окно для задания комментария при фиксации изменений в рабочей копии

Рис. 25. Состояние рабочей копии после фиксации добавления файла в репозиторий

Рис. 26. Состояние репозитория после добавления файлов из рабочих копий в проект

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

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

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

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

Рис. 28. Окно протокола синхронизации рабочей копии с репозиторием SVN

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

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

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

После синхронизации своей рабочей копии Петя решил, что функциональность модуля hello.py, который сделал Вася, его не устраивает, и внес в нее изменения. TortoiseSVN отслеживает внесение изменений в файл и информирует об этом в виде иконки (рис. 30). Поработав, Петя понял, что не все его изменения были правильные, и хочет убрать неправильные изменения из файла. Но он не помнит, что именно и где он менял. Для того чтобы вспомнить, он выполняет команду Diff над нужным файлом (рис. 31).

Рис. 30. Состояние рабочей копии Пети после внесения изменений в файл hello.py

Рис. 31. Сравнение версии файла hello.py в рабочей копии с версией в репозитории SVN

Программа сравнения файлов TortoiseMerge показывает строки файла, которые были изменены (рис. 32). Петя удаляет часть своих изменений, но тут понимает, что все внесенные им изменения были ошибочны, и хочет восстановить начальное состояние файла hello.py. Он делает Update, но состояние файла не изменяется (рис. 33).

Рис. 32. Результат сравнения разных версий файлов hello.py

Рис. 33. Окно протокола синхронизации рабочей копии с репозиторием SVN

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

Рис. 34. Откат версии файла hello.py до состояния версии в репозитории SVN

Рис. 35. Окно протокола отката версии файла hello.py

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

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

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

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

Рис. 36. Переименование файла readme.txt в рабочей копии

Рис. 37. Диалоговое окно нового имени файла

В результате выполнения команды файл помечается иконкой добавления (рис. 38). Тут возникает вопрос: почему при переименовании добавляется файл с новым именем? Дело в том, что в SVN команда Rename реализована с помощью механизма Copy-Delete. Это позволяет сохранять историю изменений файла при переименованиях.

Рис. 38. Результат переименования файла readme.txt в рабочей копии

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

Рис. 39. Диалоговое окно для задания комментария при фиксации переименования файла readme.txt в репозитории SVN

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

Петя с Васей решили выделить файлы документации в отдельную папку. Для этого Петя создает в своей рабочей копии папку doc (рис. 40). Добавляет ее под контроль SVN (рис. 41). Затем, используя технологию Drag-and-Drop и правую кнопку мыши, Петя выполняет перенос файла documentation.txt в папку doc (рис. 42). В результате папка doc выглядит следующим образом (рис. 43). Как видите, механизм переноса реализован через уже знакомый нам механизм Copy-Delete. После фиксации изменений проект в ре-позитории выглядит следующим образом (рис. 44).

Рис. 40. Состояние рабочей копии после создания папки doc

Рис. 41. Установка метки папки для ее помещения под контроль SVN

Рис. 42. Перенос файла documentation.txt, находящегося под контролем SVN, в папку doc, которая тоже находится под контролем SVN

Рис. 43. Состояние папки doc в рабочей копии после переноса файла documentation.txt

Рис. 44. Состояние репозитория SVN после фиксации переноса файла documentation.txt

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

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

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

В заключение работы Вася и Петя решили внестивфайлдокументации documentation.txt информацию о себе. Вася зафиксировал изменения на долю секунды раньше, чем Петя. Петя хочет зафиксировать свои изменения (рис. 45). Но ему не удается это сделать (рис. 46). Возникает конфликт версий файла, то есть файл, который находится в данный момент в репозитории, отличается от файла, который был в репозитории при создании рабочей копии Пети.

Рис. 45. Диалоговое окно для задания комментария при фиксации изменений в файле documentation.txt

Рис. 46. Окно протокола фиксации изменений в случае конфликта версий файла documentation.txt в рабочей копии и в репозитории

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

Рис. 47. Окно протокола синхронизации рабочей копии в случае конфликта содержимого файла documentation.txt

Рис. 48. Состояние рабочей копии в случае конфликта версий файла documentation.txt

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

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

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

  1. Неправильный вариант — откатить файл до исходного состояния, синхронизировать его с репозиторием и заново внести в него все свои изменения.
  2. Правильный вариант — разрешить конфликт средствами SVN. Дополнительные файлы, которые появились в директории, создаются как раз для помощи в этом. Для разрешения конфликта Петя с помощью команды Edit Conflicts (рис. 49) и программы TortoiseMerge, идущей в составе клиента TortoiseSVN, смотрит, где именно возник конфликт (рис. 50).

Рис. 49. Просмотр конфликта версий файла documentation.txt

Рис. 50. Детали конфликта версий файла documentation.txt в программе TortoiseMerge

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

  1. Mine («мой») — в окне представлен файл Пети, который находится в рабочей копии.
  2. Theirs («их») — в окне представлен файл Васи, который находится в репозитории. Этот файл не дает Пете зафиксировать изменения, так как файлы находятся в конфликте.
  3. Merged («слитый») — в окне представлен итоговый файл, который останется после слияния файлов mine и theirs и будет зафиксирован в репозитории. Красные строки в окнах — это и есть конфликтующие строки, видно, что в файлах Васи и Пети они разные. Оранжевые перечеркнутые строки — это строки, которые были в файле при создании рабочей копии или последней синхронизации ее с репозиторием, но были удалены из файла. Окна просмотра файлов синхронизированы между собой, что очень удобно для просмотра и разрешения конфликтов.

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

Конфликт также можно просмотреть и устранить напрямую в файле documentation.txt (рис. 51). В файле видно 3 метки:

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

Рис. 51. Детали конфликта версий файла documentation.txt

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

Контекстное меню окна Merged предлагает варианты использования строк из окон Theirs и Mine. Петя выбирает команду Use text block from ‘theirs», чтобы вставить в итоговый файл строку из файла Васи (рис. 52), и вручную дописывает строку Васи в итоговом файле. Устранив все конфликты (рис. 53) (теперь в окне Merged больше нет строк красного цвета), Петя сохраняет итоговый файл и выходит из TortoiseMerge.

Рис. 52. Устранение конфликта строк в файле documentation.txt в программе TortoiseMerge в автоматическом режиме

Рис. 53. Устранение конфликта строк в файле documentation.txt в программе TortoiseMerge в ручном режиме

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

Рис. 54. Разрешение конфликта версий файлов, возникшее при синхронизации рабочей копии с репозиторием

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

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

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

Если в проекте потребуется временно откатить некоторые папки и файлы назад, то необязательно создавать новую рабочую копию со старым номером ревизии всех файлов. Достаточно откатить только те файлы, которые нужны, с помощью команды Update to revision (рис. 55). Для этого с помощью кнопки Show log можно посмотреть историю изменений файла (рис. 56) и выбрать нужную ревизию файлов или папок для работы (рис. 57).

Рис. 55. Откат файла до нужной ревизии в репозитории SVN

Рис. 56. Диалоговое окно выбора параметров отката файла до нужной ревизии

Рис. 57. Диалоговое окно истории изменений файла для выбора нужной ревизии файла

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

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

Рис. 58. Блокировка папки в рабочей копии

Рис. 59. Диалоговое окно для комментария при фиксации изменений о блокировке папки

Рис. 60. Окно протокола фиксации изменений заблокированного файла

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

Основы систем управления версиями файлов на примере Subversion (SVN). Часть 3

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *