Работа с системой контроля версий

Общие сведения

Subversion (SVN) — это централизованная система для совместной работы. В ее основе лежит хранилище, которое содержит данные в форме дерева файловой системы — обычной иерархии файлов и каталогов. Клиенты подключаются к хранилищу и читают или изменяют эти файлы. Записывая данные, клиент делает информацию доступной для остальных. Читая данные, клиент получает информацию от других.

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

Подробная документация по настройке и использованию Subversion доступна здесь.

Основные понятия

Хранилище — центральная база данных, обычно расположенная на файловом сервере и содержащая версированные файлы с иx полной историей. Хранилище может быть доступно посредством различных сетевых протоколов или с локального диска.

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

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

Ревизии в хранилище можно представить в виде серии деревьев файловой системы — массива номеров ревизий, начинающегося с 0 и растущего слева направо (рис. 1). Под каждым номером расположено дерево файловой системы. И каждое дерево — "снимок" состояния хранилища после каждой фиксации.

Рис. 1. — Представление ревизий в хранилище

Модели версирования

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

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

Чтобы избежать подобной проблемы, используются две модели версирования:

• модель "Блокирование-Изменение-Разблокирование";
• модель "Копирование-Изменение-Слияние".

Модель "Блокирование-Изменение-Разблокирование"

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

Недостатки:

• Первый пользователь может забыть снять блокировку, что приведет к потере времени вторым разработчиком.
• Блокирование может вызвать излишнюю очередность. Если пользователи работают с разными непересекающимися частями файла (например, начало и конец), то можно было бы работать с файлом одновременно, предполагая корректное слияние изменений.
• Блокирование может вызвать ложное чувство безопасности. Пользователи могут одновременно работать с разными файлами, содержащими зависящую друг от друга функциональность. Каждый пользователь заблокировал свой файл и думает, что начинает безопасную изолированную задачу. Это препятствует заблаговременному обсуждению их изменений, которые могут быть несовместимы друг с другом, что приведет к неработоспособности разрабатываемого решения.

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

Модель "Копирование-Изменение-Слияние

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

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

Решающим фактором при использовании этой модели является взаимодействие между пользователями. При плохом взаимодействии пользователей увеличивается количество смысловых и синтаксических конфликтов.

Как рабочие копии отслеживают хранилище

В служебной папке .svn рабочей копии для каждого файла Subversion записывает информацию о двух важнейших свойствах:

• на какой ревизии основан файл в рабочей копии (рабочая ревизия файла);
• дату и время, когда локальная копия файла последний раз обновлялась из хранилища.

На основании этой информации Subversion может определить в каком из состояний находится файл рабочей копии:

1. Не изменялся и не устарел. Файл не изменялся в рабочей копии. В хранилище не фиксировались изменения этого файла со времени его рабочей ревизии. При попытке его обновить или зафиксировать ничего выполнятся не будет.
2. Изменен локально и не устарел. Файл был изменен в рабочей копии. В хранилище не фиксировались изменения этого файла со времени его базовой ревизии. Обновление выполнятся не будет. Фиксация в хранилище выполнится успешно.
3. Не изменялся и устарел. Файл в рабочей папке не изменялся, но был изменен в хранилище. Файл должен быть обновлен для соответствия текущей публичной ревизии. Фиксация выполнятся не будет. Обновление выполнится успешно.
4. Изменен локально и устарел. Файл был изменен как в рабочей папке, так и в хранилище. Попытка фиксации потерпит неудачу. Файл необходимо сначала обновить, попытавшись объединить опубликованные другим разработчиком изменения с локальными. Если Subversion не сможет выполнить объединение самостоятельно, решение конфликта будет выполнять пользователь.

Рабочая копия, используемая приложением bpm'online

При выключенном режиме разработки в файловой системе приложение bpm'online использует собственную рабочую копию каждого пользовательского пакета, для которого подключена версионность. Эти рабочие копии размещаются в каталоге, указанном в элементе defPackagesWorkingCopyPath конфигурационного файла ConnectionStrings.config (см. "Развертывание приложения on-site").

Если включен режим разработки в файловой системе, то рабочая копия может быть создана вручную в каталоге [Путь к установленному приложению]\Terrasoft.WebApp\Terrasoft.Configuration\Pkg\[Название пакета] (см. "Создание пакета в режиме разработки в файловой системе").

Клиентское приложение для работы с SVN

Для работы с Subversion (SVN) в файловой системе рекомендуется использовать клиентское приложение TortoiseSVN версии не ниже 1.9. Оно реализовано как расширение оболочки Windows и встраивается в контекстное меню проводника Windows. Подробная документация по использованию TortoiseSVN доступна здесь.

Смотрите также

• Создание пакета в режиме разработки в файловой системе
• Как установить существующий пакет из SVN в режиме разработки в файловой системе
• Привязка к SVN не связанного с хранилищем пакета
• Обновление и фиксация пакета в SVN в режиме разработки в файловой системе
• Создание пакета и переход в режим разработки в файловой системе