Архитектура SVN
Типы репозиториев
Subversion предлагает два варианта организации репозиториев:
-базы данных на основе Berkeley DB;
-обычные файлы специального формата (доступ к данным организуется с помощью собственных библиотек, без использования сторонних баз данных).
Разработчики Subversion часто называют хранилище «файловой системой», поэтому второй тип получил название FSFS, то есть версионированная файловая система (File System) поверх обычной файловой системы.
Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации.
Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок.
Каждый из них обладает своими преимуществами и недостатками:
- FSFS легче правильно настроить, она требует меньшего внимания от администратора.
до релиза 1.4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном (wedged) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS.
Модель работы
•Subversion — централизованная система, то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.
•Работа в Subversion мало отличается от работы в других централизованных системах управления версиями.
•Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище.
•Несколько клиентов могут одновременно обращаться к хранилищу.
Всвязи с тем, что разработчики работают только с локальными копиями, могут возникать трудности, когда два и более человек изменяют один и тот же файл.
ВSVN есть две модели, позволяющие избегать этой проблемы:
•Блокирование - изменение - разблокирование.
Согласно этой модели, когда кто-либо начинает работу с файлом, этот файл блокируется, и все остальные пользователи теряют возможность его редактирования.
Очевидным недостатком такой модели является то, что файлы могут оказаться надолго заблокированными, что приводит к простоям в разработке проекта.
•
•Копирование - изменение - слияние.
В данной модели каждый разработчик свободно редактирует свою
локальную копию файлов, после чего выполняется слияние изменений. Недостаток этой модели в том, что может возникать необходимость разрешения конфликтов между изменениями файла.
•Вторая модель является основной. В то же время для некоторых типов файлов (например, изображения) целесообразно использовать первую модель.
Проблема разделения файлов
Всем системам управления версиями приходится решать одну и ту же основную проблему:
-как предоставить пользователям возможность совместного использования информации,
-пользователи могут случайно перезаписать в хранилище изменения, сделанные друг другом.
•Допустим, у нас есть два соразработчика — Гарри и Салли.
•Каждый из них решил одновременно отредактировать один и тот же файл из хранилища.
•Если первым свои изменения в хранилище сохранит Гарри, то возможно, что (несколькими минутами позже) Салли может непреднамеренно перезаписать их своей новой версией файла.
•Несмотря на то, что версия файла Гарри не будет полностью потеряна (так как система помнит каждое изменение), внесенные Гарри изменения не будут отражены в новой версии файла Салли, потому что, начиная, она не видела изменения Гарри.
•Работа Гарри фактически потеряна — или, по крайней мере, отсутствует в последней версии файла — по случайности. Как раз этой ситуации мы и хотим избежать!
Проблема потери изменений (иллюстрация)
Модель Блокирование-Изменение-Разблокирование
Эта модель запрещает одновременное редактирование файла несколькими пользователями. Эксклюзивность доступа гарантируется блокировками.
Перед началом редактирования Гарри должен «заблокировать» файл. Если Гарри заблокирует файл, Салли уже не сможет его разблокировать и внести свои изменения. Ей остается только читать файл и ждать, пока Гарри закончит свои изменения и снимет блокировку. Лишь после того, как Гарри разблокирует файл, Салли сможет получить его, заблокировать и начать редактирование.
Проблемой модели блокирование-изменение-разблокирование является то, что она немного ограниченная и часто доставляет неудобства пользователям:
•Блокирование может вызвать проблемы администрирования. Иногда Гарри может заблокировать файл, а затем забыть об этом. Между тем, ожидая редактирования файла, у Салли будут связаны руки. А Гарри тем временем уехал в отпуск. Теперь Салли, для снятия блокировки Гарри, нужно обращаться к администратору. Ситуация заканчивается не нужной задержкой и потерянным временем.
•Блокирование может вызвать излишнюю пошаговость. Вполне вероятна ситуация, когда Гарри редактирует начало текстового файла, а Салли нужно отредактировать концовку этого же файла? Эти изменения совсем не перекрываются. Они могли бы легко редактировать файл одновременно, и при условии корректного слияния изменений это не вызвало бы никаких особенных проблем. Нет никакой необходимости блокировать файл в такой ситуации.
•Блокирование может вызвать ложное чувство безопасности. Предположим, что Гарри блокирует и редактирует файл А, в то время как Салли одновременно блокирует и редактирует файл В. Но допустим, что А и В зависят друг от друга и сделанные в каждом изменения семантически не совместимы. Неожиданно А и В больше не работают вместе. Блокирующая система бессильна в предотвращении проблемы — вместо этого она обеспечила ложное чувство безопасности. Для Гарри и Салли просто вообразить, что, блокируя файлы каждый начинает безопасную изолированную задачу и не беспокоиться об обсуждении их несовместимых изменений заранее. Зачастую, блокирование подменяет настоящее общение.
Модель Копирование-Изменение-Слияние
•В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию - локальное отражение файлов и каталогов хранилища.
•После этого пользователи работают одновременно и независимо друг от друга, изменяя свои личные копии.
•В конце концов, личные копии сливаются в новую, итоговую версию (система помогает, но за корректное выполнение отвечает человек) .
•В качестве примера предположим, что Гарри и Салли создали рабочие копии одного и того же проекта, скопировав их из хранилища. Они работают одновременно и в своих рабочих копиях вносят изменения в один и тот же файл А.
•Первой свои изменения в хранилище сохраняет Салли.
•Когда позже Гарри попытается сохранить свои изменения, хранилище проинформирует его о том, что его файл А устарел.
•Поэтому Гарри просит свой клиент слить любые изменения из хранилища в его рабочую копию файла А.
•По счастливому совпадению, изменения Салли не перекрываются с его собственными; после объединения обоих наборов изменений он сохраняет свою рабочую копию обратно в хранилище.
