знакомство с Subversion
Управление версиями — это искусство управления изменяющейся информацией. Долгое время оно было жизненно важным инструментом программистов, которые обычно проводят время, внося небольшие изменения в программы, а в один прекрасный момент делают откат изменений, возвращаясь к предыдущей версии. Однако, полезность систем управления версиями выходит далеко за пределы мира разработчиков программного обеспечения. Управление версиями требуется повсюду, где можно встретить людей, использующих компьютер для работы с постоянно изменяющейся информацией. Именно тогда на сцену выходит Subversion.
что такое Subversion?
Subversion — это свободная система управления версиями с открытым исходным кодом. Subversion позволяет управлять файлами и каталогами во времени. Дерево файлов помещается в центральное хранилище, которое похоже на обычный сервер файлов с тем отличием, что оно запоминает каждое изменение, внесенное в файл или каталог. Это позволяет восстановить ранние версии данных, исследовать историю изменений данных. Благодаря этому, многие считают систему управления версиями своеобразной «машиной времени».
Subversion обращается к хранилищу по сети, что позволяет использовать ее на разных компьютерах. При отсутствии единственного контролирующего звена, через которое должны проходить все изменения, работа становится более эффективной. При этом не нужно опасаться, что отказ от контролирующего звена повлияет на качество, ведь благодаря сохранению истории версий, даже если в данные будут внесены ошибочные изменения, всегда можно сделать откат изменений к прежнему состоянию.
Некоторые системы управления версиями выступают также в качестве систем управления конфигурацией программного обеспечения. Такие системы специально созданы для управления деревьями исходного кода и обладают множеством особенностей, непосредственно относящихся к разработке программного обеспечения: они понимают языки программирования и предоставляют инструменты для сборки программ. Subversion не является такой системой, она представляет собой систему общего назначения, которую можно использовать для управления любым набором файлов. Ваши файлы могут быть исходным кодом, а для кого-то это будет что-то иное, например списки покупок в продовольственном магазине или сведенные цифровые видеоролики.
основные понятия
Этот раздел представляет собой краткое, промежуточное введение в Subversion. Если контроль версий для вас в новинку, то раздел этот - специально для вас.
Несмотря на то, что примеры в этой главе показывают людей, делящих между собой набор исходников программы, помните, что Subversion может управлять набором файлов любого типа — она не ограничивается помощью программистам.
хранилище
Subversion является централизованной системой для разделения информации. В ее основе лежит хранилище, содержащее информацию в форме дерева файлов — типичного представления файлов и каталогов. Любое количество клиентов подключается к хранилищу и читает или записывает эти файлы. Записывая данные, клиент делает информацию доступной для остальных; читая данные, клиент получает информацию от других. Рисунок 1 иллюстрирует это.
Рисунок 1. Типичная клиент-серверная система.
Почему мы заостряем на этом внимание? Пока это звучит как определение типичного файл-сервера. И действительно, хранилище является разновидностью файл-сервера, однако не совсем обычного. Что делает хранилище Subversion особенным? Это то, что он запоминает каждое внесенное изменение: любое изменение любого файла, равно как изменения в самом дереве каталогов, такие как добавление, удаление и реорганизация файлов и каталогов. При чтении данных из хранилища клиент обычно видит только последнюю версию дерева файлов. Но клиент также имеет возможность просмотреть предыдущие состояния файловой системы. Например, клиент может сделать такие запросы, как «Что содержал этот каталог в прошлую среду?» или «Кто был последним изменявшим этот файл, и какие вносились изменения?» Вопросы подобного типа являются основными для любой системы контроля версий – системы, разработанной для записи и отслеживания изменений информации во времени.
модели версионирования
Основной задачей системы управления версиями является обеспечение совместного редактирования и распределения информации. Однако разные системы используют разные способы для достижения этого.
Всем системам контроля версий приходится решать одну и ту же основную проблему: как предоставить пользователям возможность совместного использования информации, при этом не позволяя им наступать друг другу на пятки? Пользователи могут просто непреднамеренно перезаписать в хранилище изменения друг друга.
Рассматриваемую ситуацию иллюстрирует Рисунок 2. Допустим у нас есть два со-разработчика Гарри и Салли. Они вдвоем решили одновременно поредактировать один и тот же файл из хранилища. Если первым свои изменения в хранилище сохранит Гарри, то возможно, что (несколькими минутами позже) Салли может непреднамеренно перезаписать их своей новой версией файла. Несмотря на то, что версия файла Гарри не будет полностью потеряна (так как система помнит каждое изменение) внесенные Гарри изменения не будут отражены в новой версии файла Сэлли, потому что, начиная, она, не видела изменения Гарри. Работа Гарри фактически потеряна — или, по крайней мере, отсутствует в последней версии файла — по случайности. Как раз этой ситуации мы и хотим избежать!
Рисунок 2. Проблема потери изменений.
модель «блокирование-изменение-разблокирование»
Для того, что бы несколько авторов не мешали друг другу, многие системы управления версиями применяют модель «блокирование-изменение- разблокирование». Эта модель запрещает одновременное редактирование файла несколькими пользователями. Эксклюзивность доступа гарантируется блокировками. Перед началом редактирования Гарри должен «заблокировать» файл. Если файл заблокировал Гарри, Салли уже не сможет его заблокировать и не сможет внести в него изменения. Ей остается только читать файл и ждать пока Гарри закончит свои изменения и снимет свою блокировку. После того, как Гарри разблокирует файл, файл сможет получить Салли, заблокировать его и начать редактирование. Рисунок 3 демонстрирует это простое решение.
Рисунок 3. Модель «блокирование-изменение-разблокирование».
Проблемой модели «блокирование-изменение-разблокирование» является то, что она имеет некоторые ограничения и часто доставляет неудобства пользователям.
Блокирование может вызвать проблемы администрирования. Иногда Гарри заблокирует файл, а затем забудет об этом. Между тем, ожидая редактирования файла, у Салли будут связаны руки. А Гарри уехал в отпуск. Теперь Салли для снятия блокировки Гарри нужно обращаться к администратору. Ситуация заканчивается ненужной задержкой и потерянным временем.
Блокирование может вызвать излишнюю пошаговость. Что если Гарри редактирует начало текстового файла, а Салли нужно отредактировать концовку этого же файла? Эти изменения совсем не перекрываются. Они могли бы легко редактировать файл одновременно и никаких особенных проблем это не вызвало бы (предполагается корректная система слияния изменений). Блокирование файла в такой ситуации не требуется.
Блокирование может вызвать ложное чувство безопасности. Предположим, что Гарри блокирует и редактирует файл А, в то время как Салли одновременно блокирует и редактирует файл В. Но допустим, что А и В зависят друг от друга и сделанные в каждом изменения семантически не совместимы. Неожиданно А и В больше не работают вместе. Блокирующая система бессильна в предотвращении проблемы — вместо этого она обеспечила ложное чувство безопасности. Для Гарри и Салли просто вообразить, что, блокируя файлы, каждый начинает безопасную изолированную задачу и не беспокоится об обсуждении их несовместимых изменений.
модель «копирование-изменение-слияние»
Subversion, CVS и другие системы управления версиями пользуются моделью «копирование-изменение-слияние» в качестве альтернативы блокированию. В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию — локальное отражение файлов и каталогов хранилища. После этого пользователи работают параллельно, изменяя свои личные копии. В конце концов, личные копии сливаются в новую, финальную версию. Обычно система управления версиями помогает в слиянии, но, разумеется, за его корректное выполнение отвечает человек. Вот пример. Скажем и Гарри и Салли создали копированием из хранилища рабочие копии одного и того же проекта. Они работают одновременно и в своих рабочих копиях вносят изменения в один и тот же файл А. Первой свои изменения в хранилище сохраняет Салли. Когда позже Гарри попытается сохранить свои изменения, хранилище проинформирует его о том, что его файл А устарел. Другими словами, файл А каким-то образом изменился со времени, когда он его последний раз копировал. Поэтому Гарри просит свой клиент слить любые изменения из хранилища в его рабочую копию файла А. По счастливому совпадению, изменения Салли не перекрываются с его собственными; после объединения обоих наборов изменений он сохраняет свою рабочую копию обратно в хранилище. Рисунки 4и 5 показывают этот процесс.
Рисунок 4. Модель копирование-изменение-слияние.
Рисунок 5. Модель копирование-изменение-слияние (продолжение).
А что если изменения Салли перекрываются с изменениями Гарри? Что тогда? Эта ситуация называется конфликтом и, как правило, это не является большой проблемой. Когда Гарри просит свой клиент слить последние изменения хранилища в рабочую копию, его копия файла А помечается как находящаяся в состоянии конфликта: у него будет возможность видеть оба набора конфликтующих изменений и вручную сделать между ними выбор. Помните, что ПО не может автоматически разрешать конфликты; только человек способен к пониманию и выполнению осмысленного выбора. Разрешив вручную перекрывающиеся изменения - возможно, после обсуждения с Салли — он может безопасно сохранить объединенный файл обратно в хранилище. Модель «копирование-изменение-слияние» может выглядеть немного хаотично, однако, на практике она отлично работает. Пользователи могут работать параллельно, не тратя времени на ожидание. При работе над одними и теми же файлами оказывается, что большинство параллельно вносимых изменений совсем не перекрываются; конфликты бывают редко. И время, которое было потрачено на разрешение конфликтов значительно меньше времени, отнимаемого блокирующей системой.
Наконец, все сходится к такому критическому фактору, как взаимодействие пользователей. При плохом взаимопонимании увеличивается количество как синтаксических, так и семантических конфликтов. Нет системы, которая может повысить уровень взаимопонимания, и нет системы, которая может определять семантические конфликты. Не стоит возлагать большие надежды на то, что блокирующая система лучше защищена от конфликтов; на практике блокирование снижает продуктивность как ничто другое.
когда блокирование необходимо
Несмотря на то, что модель «блокирование-изменение-разблокирование» названа, в целом, губительной для командной работы, все-таки есть моменты, когда блокирование уместно.
Модель копирование-изменение-слияние основывается на предположении о том, что файлы контекстно-объединяемы: это так, если большинство файлов в хранилище — текстовые файлы (например, исходный код программы). Но для файлов бинарных форматов, таких как графические или звуковые, как правило, невозможно объединить конфликтующие изменения. В таких ситуациях пользователям действительно необходимо быть внимательными при изменении файла. Без раздельного доступа кто-то может впустую потратить время на изменения, которые, в конце концов, будут потеряны. Так как и CVS, и Subversion, — в первую очередь системы типа «копирование-изменение-слияние», то в них обоих признается необходимость блокирования определенных файлов и предлагаются соответствующие механизмы.
возможности и преимущества Subversion
Обсуждать возможности Subversion удобнее всего в разрезе ее улучшений по сравнению с CVS. Так мы и поступим.
Управление версиями каталогов. CVS следит только за историей отдельных файлов, тогда как Subversion использует «виртуальную» файловую систему с возможностями управления версиями, которая способна отслеживать изменения во времени целых деревьев каталогов. То есть под управление версиями попадают и файлы, и каталоги.
Настоящая история версий. CVS ограничивается управлением версиями файлов, поэтому такие операции, как копирование и переименование, хотя и относящиеся к файлам, но по существу являющиеся изменениями каталогов, содержащих эти файлы, в CVS не поддерживаются. Кроме того, в CVS вы не можете заменить файл, помещенный под управление версиями, другим файлом с тем же именем, но совершенно иным содержанием, возможно никак не связанным со старым объектом, без наследования таким элементом всей истории изменений. Subversion делает возможным добавление, удаление, копирование и переименование как файлов, так и каталогов. При этом каждый вновь добавленный файл начинает жизнь с чистого листа, сохраняя собственную историю изменений.
Атомарные закрепления изменений. Каждый набор изменений либо попадает в хранилище целиком, либо не попадает туда вовсе. Это позволяет разработчикам создавать и закреплять изменения логически оправданными кусками, предотвращая тем самым проблемы, которые могут возникать в тех случаях, когда только часть необходимых изменений помещается в хранилище успешно.
Метаданные с версиями. Каждый файл и каталог имеет собственный набор свойств, представленных в виде названия и значения. Вы можете создавать и сохранять любые необходимые пары названий свойств и их значений. Свойства файлов точно так же находятся под управлением версиями, как и их содержимое.
Выбор средств доступа к хранилищу по сети. В Subversion используется абстракция доступа к хранилищу, что позволяет реализовывать самые разные сетевые механизмы доступа. Subversion может быть подключена к Apache в виде модуля, что дает ей огромное преимущество с точки зрения устойчивости работы и способности к взаимодействию, а также предоставляет прямой доступ к существующим возможностям этого сервера, включая установление личности, проверку прав доступа и сжатие информации при передаче. Кроме того, имеется легкий самостоятельный сервер Subversion, который использует собственный протокол взаимодействия с клиентами и может легко туннелировать данные через SSH.
Единый способ работы с данными. Subversion обнаруживает различия между файлами с помощью специального бинарного алгоритма, который одинаково работает как с текстовыми, так и с бинарными файлами. Файлы записываются в хранилище в сжатом виде независимо от их типа, а различия между отдельными версиями могут передаваться по сети в обоих направлениях.
Эффективные ветки и метки. Плата за использование веток и меток не должна быть пропорциональна размеру проекта. Subversion создает ветки и метки путем простого копирования проекта, используя механизм, похожий на жесткие ссылки в файловых системах. Благодаря этому операции по созданию веток и меток занимают немного времени.
Дружелюбность по отношению к разработчикам. Subversion не имеет исторического багажа. Она реализована в виде набора динамических библиотек на языке C, API которых хорошо известен. Это делает Subversion чрезвычайно удобной с точки зрения сопровождения системой, пригодной для взаимодействия с другими приложениями и языками программирования.
установка Subversion
Subversion построена на портабельном слое под названием APR (the Apache Portable Runtime library). Библиотека APR предоставляет все интерфейсы, необходимые для функционирования Subversion под управлением различных операционных систем: доступ к жесткому диску, доступ к сети, управление памятью и тому подобное. Несмотря на то, что Subversion может использовать Apache как сервер, ее зависимость от Apache не означает того, что Apache является необходимым компонентом. APR представляет собой отдельную библиотеку, которую может использовать любое приложение. Кроме прочего, это означает, что, как и Apache, Subversion-клиенты и серверы работают на любой операционной системе, на которой работает HTTP-сервер Apache: Windows, Linux, все разновидности BSD, MacOS X, Netware и другие.
Наиболее простой способ получить Subversion - скачать бинарный пакет, собранный для вашей операционной системы. Как правило, эти пакеты, присланные волонтерами, доступны для загрузки с веб-сайта Subversion (subversion.tigris.org). На сайте вы найдете и графический инсталлятор для пользователей операционных систем Microsoft.
Если вы используете Unix-подобную ОС то для получения Subversion вы можете использовать пакетную систему, специфичную для вашей системы (RPM, DEB, ports tree и т. д.).
В качестве альтернативного варианта вы можете построить Subversion прямо из исходного кода. Закачайте с веб-сайта Subversion последний source- code релиз. После его распаковки для его сборки следуйте инструкциям в файле INSTALL. Обратите внимание, что такой пакет содержит все необходимое для сборки CLI-клиента, способного работать с удаленным хранилищем (обычно это библиотеки apr, apr-util и neon). Однако некоторые опциональные части Subversion имеют много других зависимостей, таких как Berkeley DB и, возможно, Apache httpd. Если вы хотите выполнить полную сборку, убедитесь, что у вас есть все пакеты, указанные в файле INSTALL. Если вы хотите самостоятельно поработать над Subversion, вы можете при помощи вашей клиентской программы вытащить самую последнюю версию исходного кода.
компоненты Subversion
Установленная Subversion имеет определенное количество компонентов. Вот краткий обзор того, что вы получаете, установив пакет:
- svn - CLI-клиент;
- svnversion – программа, показывающая состояние (в пределах ревизий существующих элементов) рабочей копии;
- svnlook - инструмент для контроля Subversion-хранилища;
- svnadmin - инструмент для создания, настройки или восстановления Subversion-хранилища;
- svndumpfilter - программа для фильтрации дамповых потоков Subversion-хранилища;
- mod_dav_svn - подключаемый модуль для HTTP-сервера Apache, использующийся для предоставления сетевого доступа к вашему хранилищу; - svnserve - собственный отдельный сервер, запускается как процесс-демон и доступен посредством SSH; еще один способ для предоставления сетевого доступа к хранилищу.
При условии корректно установленной Subversion вы готовы к старту.
быстрый старт
Некоторые испытывают трудности восприятия новой технологии, читая приближение «с верху вниз», традиционное для академической литературы. Этот раздел представляет собой очень короткое введение в Subversion и предназначен для того, что бы помочь изучающим технологии по методу «снизу вверх». Если вы из тех, кто предпочитает учиться на экспериментах, то последующая демонстрация поможет вам начать.
Subversion хранит всю версионированную информацию в центральном хранилище. Для начала, создадим новое хранилище:
$ svnadmin create /path/to/repos
$ ls /path/to/repos
conf/ dav/ db/ format hooks/ locks/ README.txt
Эта команда создает новую директорию /path/to/repos содержащую Subversion-хранилище. Убедитесь, что эта директория находится на локальном диске, не на сетевой шаре. Эта новая директория (кроме прочего) содержит набор файлов базы данных.
У Subversion нет понятия «проект». Хранилище является просто виртуальной версионированной файловой системой - большое дерево файлов, которое может содержать все, что угодно. Одни администраторы предпочитают держать в хранилище только один проект, другие держат в хранилище множество проектов, размещая их в отдельных директориях. Достоинства каждого из подходов рассмотрены в «Choosing a Repository Layout». В любом случае, хранилище управляет только файлами и директориями, оставляя за человеком право интерпретировать отдельные директории как «проекты». Поэтому, если в тексте книги вы встретите упоминание проекта, помните, что имеется в виду просто директория (или несколько директорий) хранилища. В этом примере мы подразумеваем наличие у вас какого-то проекта (набора файлов или директорий), который вы хотите импортировать в только что созданное Subversion-хранилище. Начните с объединения их в отдельной директории, названой myproject (или как-то иначе). Ваше дерево проекта должно содержать три директории верхнего уровня с названиями branches, tags и trunk. Вся ваша информация должна находиться в директории trunk, а директории branches и tags должны быть пустыми:
/tmp/myproject/branches/
/tmp/myproject/tags/
/tmp/myproject/trunk/
foo.c
bar.c
Makefile
…
Использовать поддиректории branches, tags и trunk не обязательно. Просто такой подход чаще всего используется, и вероятнее всего в дальнейшем вы будете использовать именно его.
Как только вы получите готовое дерево данных, импортируйте его в хранилище при помощи команды svn import:
$ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
Adding /tmp/myproject/branches
Adding /tmp/myproject/tags
Adding /tmp/myproject/trunk
Adding /tmp/myproject/trunk/foo.c
Adding /tmp/myproject/trunk/bar.c
Adding /tmp/myproject/trunk/Makefile
…
Committed revision 1.
Теперь в хранилище находится это дерево данных. Вы не увидите своих файлов, если загляните в хранилище напрямую; все хранится в базе данных. Однако сейчас воображаемая файловая системы хранилища имеет директорию верхнего уровня с названием myproject, где находится ваша информация. Обратите внимание на то, что первоначальная директория остается без изменений; Subversion о ней не знает (при желании, вы можете даже удалить этот каталог).
Чтобы начать работать с информацией хранилища вам нужно создать новую «рабочую копию» информации, своего рода частное рабочее пространство. Попросите Subversion создать рабочую копию директории myproject/trunk хранилища:
$ svn checkout file:///path/to/repos/myproject/trunk myproject
A myproject/foo.c
A myproject/bar.c
A myproject/Makefile
…
Checked out revision 1.
Сейчас у вас в новой директории myproject есть личная копия части хранилища. В рабочей копии вы можете редактировать файлы, а затем зафиксировать внесенные изменения в хранилище.
Откройте свою рабочую копию и отредактируйте содержимое файлов.
Выполните svn diff чтобы увидеть объединенный diff внесенных изменений.
Выполните svn commit для фиксации новой версии ваших файлов в хранилище.
Выполните svn update для приведения рабочей копии в «актуальное» состояние по отношению к хранилищу.
Для получения полного списка возможных действий с рабочей копией прочтите соответсвующую документацию.
После этого вы можете сделать ваше хранилище доступным для других через сеть.
Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато.
что такое Subversion?
Subversion — это свободная система управления версиями с открытым исходным кодом. Subversion позволяет управлять файлами и каталогами во времени. Дерево файлов помещается в центральное хранилище, которое похоже на обычный сервер файлов с тем отличием, что оно запоминает каждое изменение, внесенное в файл или каталог. Это позволяет восстановить ранние версии данных, исследовать историю изменений данных. Благодаря этому, многие считают систему управления версиями своеобразной «машиной времени».
Subversion обращается к хранилищу по сети, что позволяет использовать ее на разных компьютерах. При отсутствии единственного контролирующего звена, через которое должны проходить все изменения, работа становится более эффективной. При этом не нужно опасаться, что отказ от контролирующего звена повлияет на качество, ведь благодаря сохранению истории версий, даже если в данные будут внесены ошибочные изменения, всегда можно сделать откат изменений к прежнему состоянию.
Некоторые системы управления версиями выступают также в качестве систем управления конфигурацией программного обеспечения. Такие системы специально созданы для управления деревьями исходного кода и обладают множеством особенностей, непосредственно относящихся к разработке программного обеспечения: они понимают языки программирования и предоставляют инструменты для сборки программ. Subversion не является такой системой, она представляет собой систему общего назначения, которую можно использовать для управления любым набором файлов. Ваши файлы могут быть исходным кодом, а для кого-то это будет что-то иное, например списки покупок в продовольственном магазине или сведенные цифровые видеоролики.
основные понятия
Этот раздел представляет собой краткое, промежуточное введение в Subversion. Если контроль версий для вас в новинку, то раздел этот - специально для вас.
Несмотря на то, что примеры в этой главе показывают людей, делящих между собой набор исходников программы, помните, что Subversion может управлять набором файлов любого типа — она не ограничивается помощью программистам.
хранилище
Subversion является централизованной системой для разделения информации. В ее основе лежит хранилище, содержащее информацию в форме дерева файлов — типичного представления файлов и каталогов. Любое количество клиентов подключается к хранилищу и читает или записывает эти файлы. Записывая данные, клиент делает информацию доступной для остальных; читая данные, клиент получает информацию от других. Рисунок 1 иллюстрирует это.
Рисунок 1. Типичная клиент-серверная система.
Почему мы заостряем на этом внимание? Пока это звучит как определение типичного файл-сервера. И действительно, хранилище является разновидностью файл-сервера, однако не совсем обычного. Что делает хранилище Subversion особенным? Это то, что он запоминает каждое внесенное изменение: любое изменение любого файла, равно как изменения в самом дереве каталогов, такие как добавление, удаление и реорганизация файлов и каталогов. При чтении данных из хранилища клиент обычно видит только последнюю версию дерева файлов. Но клиент также имеет возможность просмотреть предыдущие состояния файловой системы. Например, клиент может сделать такие запросы, как «Что содержал этот каталог в прошлую среду?» или «Кто был последним изменявшим этот файл, и какие вносились изменения?» Вопросы подобного типа являются основными для любой системы контроля версий – системы, разработанной для записи и отслеживания изменений информации во времени.
модели версионирования
Основной задачей системы управления версиями является обеспечение совместного редактирования и распределения информации. Однако разные системы используют разные способы для достижения этого.
Всем системам контроля версий приходится решать одну и ту же основную проблему: как предоставить пользователям возможность совместного использования информации, при этом не позволяя им наступать друг другу на пятки? Пользователи могут просто непреднамеренно перезаписать в хранилище изменения друг друга.
Рассматриваемую ситуацию иллюстрирует Рисунок 2. Допустим у нас есть два со-разработчика Гарри и Салли. Они вдвоем решили одновременно поредактировать один и тот же файл из хранилища. Если первым свои изменения в хранилище сохранит Гарри, то возможно, что (несколькими минутами позже) Салли может непреднамеренно перезаписать их своей новой версией файла. Несмотря на то, что версия файла Гарри не будет полностью потеряна (так как система помнит каждое изменение) внесенные Гарри изменения не будут отражены в новой версии файла Сэлли, потому что, начиная, она, не видела изменения Гарри. Работа Гарри фактически потеряна — или, по крайней мере, отсутствует в последней версии файла — по случайности. Как раз этой ситуации мы и хотим избежать!
Рисунок 2. Проблема потери изменений.
модель «блокирование-изменение-разблокирование»
Для того, что бы несколько авторов не мешали друг другу, многие системы управления версиями применяют модель «блокирование-изменение- разблокирование». Эта модель запрещает одновременное редактирование файла несколькими пользователями. Эксклюзивность доступа гарантируется блокировками. Перед началом редактирования Гарри должен «заблокировать» файл. Если файл заблокировал Гарри, Салли уже не сможет его заблокировать и не сможет внести в него изменения. Ей остается только читать файл и ждать пока Гарри закончит свои изменения и снимет свою блокировку. После того, как Гарри разблокирует файл, файл сможет получить Салли, заблокировать его и начать редактирование. Рисунок 3 демонстрирует это простое решение.
Рисунок 3. Модель «блокирование-изменение-разблокирование».
Проблемой модели «блокирование-изменение-разблокирование» является то, что она имеет некоторые ограничения и часто доставляет неудобства пользователям.
Блокирование может вызвать проблемы администрирования. Иногда Гарри заблокирует файл, а затем забудет об этом. Между тем, ожидая редактирования файла, у Салли будут связаны руки. А Гарри уехал в отпуск. Теперь Салли для снятия блокировки Гарри нужно обращаться к администратору. Ситуация заканчивается ненужной задержкой и потерянным временем.
Блокирование может вызвать излишнюю пошаговость. Что если Гарри редактирует начало текстового файла, а Салли нужно отредактировать концовку этого же файла? Эти изменения совсем не перекрываются. Они могли бы легко редактировать файл одновременно и никаких особенных проблем это не вызвало бы (предполагается корректная система слияния изменений). Блокирование файла в такой ситуации не требуется.
Блокирование может вызвать ложное чувство безопасности. Предположим, что Гарри блокирует и редактирует файл А, в то время как Салли одновременно блокирует и редактирует файл В. Но допустим, что А и В зависят друг от друга и сделанные в каждом изменения семантически не совместимы. Неожиданно А и В больше не работают вместе. Блокирующая система бессильна в предотвращении проблемы — вместо этого она обеспечила ложное чувство безопасности. Для Гарри и Салли просто вообразить, что, блокируя файлы, каждый начинает безопасную изолированную задачу и не беспокоится об обсуждении их несовместимых изменений.
модель «копирование-изменение-слияние»
Subversion, CVS и другие системы управления версиями пользуются моделью «копирование-изменение-слияние» в качестве альтернативы блокированию. В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию — локальное отражение файлов и каталогов хранилища. После этого пользователи работают параллельно, изменяя свои личные копии. В конце концов, личные копии сливаются в новую, финальную версию. Обычно система управления версиями помогает в слиянии, но, разумеется, за его корректное выполнение отвечает человек. Вот пример. Скажем и Гарри и Салли создали копированием из хранилища рабочие копии одного и того же проекта. Они работают одновременно и в своих рабочих копиях вносят изменения в один и тот же файл А. Первой свои изменения в хранилище сохраняет Салли. Когда позже Гарри попытается сохранить свои изменения, хранилище проинформирует его о том, что его файл А устарел. Другими словами, файл А каким-то образом изменился со времени, когда он его последний раз копировал. Поэтому Гарри просит свой клиент слить любые изменения из хранилища в его рабочую копию файла А. По счастливому совпадению, изменения Салли не перекрываются с его собственными; после объединения обоих наборов изменений он сохраняет свою рабочую копию обратно в хранилище. Рисунки 4и 5 показывают этот процесс.
Рисунок 4. Модель копирование-изменение-слияние.
Рисунок 5. Модель копирование-изменение-слияние (продолжение).
А что если изменения Салли перекрываются с изменениями Гарри? Что тогда? Эта ситуация называется конфликтом и, как правило, это не является большой проблемой. Когда Гарри просит свой клиент слить последние изменения хранилища в рабочую копию, его копия файла А помечается как находящаяся в состоянии конфликта: у него будет возможность видеть оба набора конфликтующих изменений и вручную сделать между ними выбор. Помните, что ПО не может автоматически разрешать конфликты; только человек способен к пониманию и выполнению осмысленного выбора. Разрешив вручную перекрывающиеся изменения - возможно, после обсуждения с Салли — он может безопасно сохранить объединенный файл обратно в хранилище. Модель «копирование-изменение-слияние» может выглядеть немного хаотично, однако, на практике она отлично работает. Пользователи могут работать параллельно, не тратя времени на ожидание. При работе над одними и теми же файлами оказывается, что большинство параллельно вносимых изменений совсем не перекрываются; конфликты бывают редко. И время, которое было потрачено на разрешение конфликтов значительно меньше времени, отнимаемого блокирующей системой.
Наконец, все сходится к такому критическому фактору, как взаимодействие пользователей. При плохом взаимопонимании увеличивается количество как синтаксических, так и семантических конфликтов. Нет системы, которая может повысить уровень взаимопонимания, и нет системы, которая может определять семантические конфликты. Не стоит возлагать большие надежды на то, что блокирующая система лучше защищена от конфликтов; на практике блокирование снижает продуктивность как ничто другое.
когда блокирование необходимо
Несмотря на то, что модель «блокирование-изменение-разблокирование» названа, в целом, губительной для командной работы, все-таки есть моменты, когда блокирование уместно.
Модель копирование-изменение-слияние основывается на предположении о том, что файлы контекстно-объединяемы: это так, если большинство файлов в хранилище — текстовые файлы (например, исходный код программы). Но для файлов бинарных форматов, таких как графические или звуковые, как правило, невозможно объединить конфликтующие изменения. В таких ситуациях пользователям действительно необходимо быть внимательными при изменении файла. Без раздельного доступа кто-то может впустую потратить время на изменения, которые, в конце концов, будут потеряны. Так как и CVS, и Subversion, — в первую очередь системы типа «копирование-изменение-слияние», то в них обоих признается необходимость блокирования определенных файлов и предлагаются соответствующие механизмы.
возможности и преимущества Subversion
Обсуждать возможности Subversion удобнее всего в разрезе ее улучшений по сравнению с CVS. Так мы и поступим.
Управление версиями каталогов. CVS следит только за историей отдельных файлов, тогда как Subversion использует «виртуальную» файловую систему с возможностями управления версиями, которая способна отслеживать изменения во времени целых деревьев каталогов. То есть под управление версиями попадают и файлы, и каталоги.
Настоящая история версий. CVS ограничивается управлением версиями файлов, поэтому такие операции, как копирование и переименование, хотя и относящиеся к файлам, но по существу являющиеся изменениями каталогов, содержащих эти файлы, в CVS не поддерживаются. Кроме того, в CVS вы не можете заменить файл, помещенный под управление версиями, другим файлом с тем же именем, но совершенно иным содержанием, возможно никак не связанным со старым объектом, без наследования таким элементом всей истории изменений. Subversion делает возможным добавление, удаление, копирование и переименование как файлов, так и каталогов. При этом каждый вновь добавленный файл начинает жизнь с чистого листа, сохраняя собственную историю изменений.
Атомарные закрепления изменений. Каждый набор изменений либо попадает в хранилище целиком, либо не попадает туда вовсе. Это позволяет разработчикам создавать и закреплять изменения логически оправданными кусками, предотвращая тем самым проблемы, которые могут возникать в тех случаях, когда только часть необходимых изменений помещается в хранилище успешно.
Метаданные с версиями. Каждый файл и каталог имеет собственный набор свойств, представленных в виде названия и значения. Вы можете создавать и сохранять любые необходимые пары названий свойств и их значений. Свойства файлов точно так же находятся под управлением версиями, как и их содержимое.
Выбор средств доступа к хранилищу по сети. В Subversion используется абстракция доступа к хранилищу, что позволяет реализовывать самые разные сетевые механизмы доступа. Subversion может быть подключена к Apache в виде модуля, что дает ей огромное преимущество с точки зрения устойчивости работы и способности к взаимодействию, а также предоставляет прямой доступ к существующим возможностям этого сервера, включая установление личности, проверку прав доступа и сжатие информации при передаче. Кроме того, имеется легкий самостоятельный сервер Subversion, который использует собственный протокол взаимодействия с клиентами и может легко туннелировать данные через SSH.
Единый способ работы с данными. Subversion обнаруживает различия между файлами с помощью специального бинарного алгоритма, который одинаково работает как с текстовыми, так и с бинарными файлами. Файлы записываются в хранилище в сжатом виде независимо от их типа, а различия между отдельными версиями могут передаваться по сети в обоих направлениях.
Эффективные ветки и метки. Плата за использование веток и меток не должна быть пропорциональна размеру проекта. Subversion создает ветки и метки путем простого копирования проекта, используя механизм, похожий на жесткие ссылки в файловых системах. Благодаря этому операции по созданию веток и меток занимают немного времени.
Дружелюбность по отношению к разработчикам. Subversion не имеет исторического багажа. Она реализована в виде набора динамических библиотек на языке C, API которых хорошо известен. Это делает Subversion чрезвычайно удобной с точки зрения сопровождения системой, пригодной для взаимодействия с другими приложениями и языками программирования.
установка Subversion
Subversion построена на портабельном слое под названием APR (the Apache Portable Runtime library). Библиотека APR предоставляет все интерфейсы, необходимые для функционирования Subversion под управлением различных операционных систем: доступ к жесткому диску, доступ к сети, управление памятью и тому подобное. Несмотря на то, что Subversion может использовать Apache как сервер, ее зависимость от Apache не означает того, что Apache является необходимым компонентом. APR представляет собой отдельную библиотеку, которую может использовать любое приложение. Кроме прочего, это означает, что, как и Apache, Subversion-клиенты и серверы работают на любой операционной системе, на которой работает HTTP-сервер Apache: Windows, Linux, все разновидности BSD, MacOS X, Netware и другие.
Наиболее простой способ получить Subversion - скачать бинарный пакет, собранный для вашей операционной системы. Как правило, эти пакеты, присланные волонтерами, доступны для загрузки с веб-сайта Subversion (subversion.tigris.org). На сайте вы найдете и графический инсталлятор для пользователей операционных систем Microsoft.
Если вы используете Unix-подобную ОС то для получения Subversion вы можете использовать пакетную систему, специфичную для вашей системы (RPM, DEB, ports tree и т. д.).
В качестве альтернативного варианта вы можете построить Subversion прямо из исходного кода. Закачайте с веб-сайта Subversion последний source- code релиз. После его распаковки для его сборки следуйте инструкциям в файле INSTALL. Обратите внимание, что такой пакет содержит все необходимое для сборки CLI-клиента, способного работать с удаленным хранилищем (обычно это библиотеки apr, apr-util и neon). Однако некоторые опциональные части Subversion имеют много других зависимостей, таких как Berkeley DB и, возможно, Apache httpd. Если вы хотите выполнить полную сборку, убедитесь, что у вас есть все пакеты, указанные в файле INSTALL. Если вы хотите самостоятельно поработать над Subversion, вы можете при помощи вашей клиентской программы вытащить самую последнюю версию исходного кода.
компоненты Subversion
Установленная Subversion имеет определенное количество компонентов. Вот краткий обзор того, что вы получаете, установив пакет:
- svn - CLI-клиент;
- svnversion – программа, показывающая состояние (в пределах ревизий существующих элементов) рабочей копии;
- svnlook - инструмент для контроля Subversion-хранилища;
- svnadmin - инструмент для создания, настройки или восстановления Subversion-хранилища;
- svndumpfilter - программа для фильтрации дамповых потоков Subversion-хранилища;
- mod_dav_svn - подключаемый модуль для HTTP-сервера Apache, использующийся для предоставления сетевого доступа к вашему хранилищу; - svnserve - собственный отдельный сервер, запускается как процесс-демон и доступен посредством SSH; еще один способ для предоставления сетевого доступа к хранилищу.
При условии корректно установленной Subversion вы готовы к старту.
быстрый старт
Некоторые испытывают трудности восприятия новой технологии, читая приближение «с верху вниз», традиционное для академической литературы. Этот раздел представляет собой очень короткое введение в Subversion и предназначен для того, что бы помочь изучающим технологии по методу «снизу вверх». Если вы из тех, кто предпочитает учиться на экспериментах, то последующая демонстрация поможет вам начать.
Subversion хранит всю версионированную информацию в центральном хранилище. Для начала, создадим новое хранилище:
$ svnadmin create /path/to/repos
$ ls /path/to/repos
conf/ dav/ db/ format hooks/ locks/ README.txt
Эта команда создает новую директорию /path/to/repos содержащую Subversion-хранилище. Убедитесь, что эта директория находится на локальном диске, не на сетевой шаре. Эта новая директория (кроме прочего) содержит набор файлов базы данных.
У Subversion нет понятия «проект». Хранилище является просто виртуальной версионированной файловой системой - большое дерево файлов, которое может содержать все, что угодно. Одни администраторы предпочитают держать в хранилище только один проект, другие держат в хранилище множество проектов, размещая их в отдельных директориях. Достоинства каждого из подходов рассмотрены в «Choosing a Repository Layout». В любом случае, хранилище управляет только файлами и директориями, оставляя за человеком право интерпретировать отдельные директории как «проекты». Поэтому, если в тексте книги вы встретите упоминание проекта, помните, что имеется в виду просто директория (или несколько директорий) хранилища. В этом примере мы подразумеваем наличие у вас какого-то проекта (набора файлов или директорий), который вы хотите импортировать в только что созданное Subversion-хранилище. Начните с объединения их в отдельной директории, названой myproject (или как-то иначе). Ваше дерево проекта должно содержать три директории верхнего уровня с названиями branches, tags и trunk. Вся ваша информация должна находиться в директории trunk, а директории branches и tags должны быть пустыми:
/tmp/myproject/branches/
/tmp/myproject/tags/
/tmp/myproject/trunk/
foo.c
bar.c
Makefile
…
Использовать поддиректории branches, tags и trunk не обязательно. Просто такой подход чаще всего используется, и вероятнее всего в дальнейшем вы будете использовать именно его.
Как только вы получите готовое дерево данных, импортируйте его в хранилище при помощи команды svn import:
$ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
Adding /tmp/myproject/branches
Adding /tmp/myproject/tags
Adding /tmp/myproject/trunk
Adding /tmp/myproject/trunk/foo.c
Adding /tmp/myproject/trunk/bar.c
Adding /tmp/myproject/trunk/Makefile
…
Committed revision 1.
Теперь в хранилище находится это дерево данных. Вы не увидите своих файлов, если загляните в хранилище напрямую; все хранится в базе данных. Однако сейчас воображаемая файловая системы хранилища имеет директорию верхнего уровня с названием myproject, где находится ваша информация. Обратите внимание на то, что первоначальная директория остается без изменений; Subversion о ней не знает (при желании, вы можете даже удалить этот каталог).
Чтобы начать работать с информацией хранилища вам нужно создать новую «рабочую копию» информации, своего рода частное рабочее пространство. Попросите Subversion создать рабочую копию директории myproject/trunk хранилища:
$ svn checkout file:///path/to/repos/myproject/trunk myproject
A myproject/foo.c
A myproject/bar.c
A myproject/Makefile
…
Checked out revision 1.
Сейчас у вас в новой директории myproject есть личная копия части хранилища. В рабочей копии вы можете редактировать файлы, а затем зафиксировать внесенные изменения в хранилище.
Откройте свою рабочую копию и отредактируйте содержимое файлов.
Выполните svn diff чтобы увидеть объединенный diff внесенных изменений.
Выполните svn commit для фиксации новой версии ваших файлов в хранилище.
Выполните svn update для приведения рабочей копии в «актуальное» состояние по отношению к хранилищу.
Для получения полного списка возможных действий с рабочей копией прочтите соответсвующую документацию.
После этого вы можете сделать ваше хранилище доступным для других через сеть.
Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато.
Сетевые решения. Статья была опубликована в номере 07 за 2006 год в рубрике software
