Проблемы Информационных Технологий 5 Информатизация общества 6 Проектирование веб-портала 8 техническое задание

Вид материала

Содержание

3.6.6. Subversion Управление версиями
Модель работы
Типы репозиториев
Доступ к репозиторию
Архитектура Subversion
Компоненты Subversion
Рабочая копия
Структура проекта в хранилище
Создание ветвей
Другие применения команды svn merge
Subversion и CVS Сравнение

Подобный материал:

1 ... 5 6 7 8 9 10 11 12 13

3.6.6. Subversion Управление версиями

Subversion — свободная централизованная система управления версиями, созданная в 2000 г. компанией CollabNet Inc.

Subversion используется многими сообществами разработчиков открытого программного обеспечения. В их числе такие известные проекты, как Apache, KDE, GCC, Free Pascal, Python, Ruby, Mono, FreeBSD. Хостинг Subversion для проектов с открытым кодом предоставляют SourceForge.net и Tigris.org. Subversion используется в системах Google Code и BountySource. Также Subversion широко используется в корпоративной сфере.

Subversion часто называют «SVN», по названию клиентской программы, входящей в её дистрибутив.

Справка. В мире программного обеспечения с открытым исходным кодом в качестве инструмента управления версиями долгое время использовалась Concurrent Versions System (CVS). CVS сама по себе является свободным программным обеспечением, на работу с ней не накладывается ограничений, а поддержка сетевых возможностей позволяет десяткам географически разделённых программистов работать совместно — всё это отлично подходит для мира свободного программного обеспечения, отличающегося духом сотрудничества. Subversion создаётся как система с открытым исходным кодом, которая по своему устройству и ощущениям от работы напоминает CVS, а во-вторых, она пытается исправить наиболее очевидные недостатки CVS. И хотя то, что получается в результате, не обязательно является новым витком в развитии технологий управления версиями, Subversion на самом деле очень мощное, удобное и гибкое средство. Сегодня едва ли не все новые проекты с открытым исходным кодом вместо CVS выбирают Subversion.

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

Модель работы

Subversion — централизованная система (в отличие от распределённых систем, таких, как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.

Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель Копирование-Изменение-Слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель Блокирование-Изменение-Разблокирование.

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

Возможности

Реализовано большинство возможностей CVS;
отслеживается история файлов, директорий и метаданных файлов и директорий, в том числе при переименовании и копировании;
атомарная фиксация изменений;
возможность организации доступа к хранилищу Subversion через Apache по протоколу WebDAV/DeltaV;
возможность установки автономного сервера Subversion с доступом по собственному протоколу;
«дешёвые» операции создания ветвей и меток (требуется небольшое фиксированное количество временных и дисковых ресурсов);
многоуровневая архитектура библиотек, изначально рассчитанная на клиент-серверную модель;
клиент-серверный протокол разработан для пересылки по сети только разницы между объектами, когда это возможно;
затраты ресурсов пропорциональны размеру изменений, а не размеру данных, которые затронуты изменениями;
два возможных внутренних формата хранилища (англ. repository): база данных или набор обычных файлов;
версионированные символьные ссылки (только в рабочих копиях под UNIX-системами);
одинаково эффективная работа и с текстовыми, и с двоичными файлами.
Вывод клиента командной строки одинаково удобен и для чтения, и для разбора программами;
интернационализированные сообщения программы (используются настройки локали);
библиотеки для языков PHP, Python, Perl, Java позволяют встроить функциональность клиента Subversion в программы, написанные на этих языках;
возможность зеркалирования хранилища.

Типы репозиториев

Subversion предлагает два варианта организации репозиториев. Репозитории первого типа используют для хранения базы данных на основе Berkeley DB, репозитории второго типа — обычные файлы специального формата (доступ к данным организуется с помощью собственных библиотек, без использования сторонних баз данных). Разработчики Subversion часто называют хранилище «файловой системой», поэтому второй тип получил название FSFS, то есть (версионированная) файловая система (англ. File System) поверх (обычной) файловой системы.

Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации (Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок), каждая из них обладает своими преимуществами и недостатками. Считается, что FSFS легче правильно настроить, она требует меньшего внимания от администратора. Кроме того, до релиза 1.4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном (англ. wedged) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS.

Доступ к репозиторию

Начиная с версии 1.4 Subversion предоставляет следующие способы доступа к репозиториям:

Локальная или сетевая файловая система — используется напрямую клиентской программой Subversion;
WebDAV/DeltaV (поверх http или https) с использованием модуля mod_dav_svn для Apache 2;
собственный протокол «svn» (порт по умолчанию 3690) использует простой текст или через SSH.

Все эти способы могут быть использованы для работы с репозиторями обоих типов (FSFS и Berkeley DB). Для доступа к одному и тому же репозиторию могут одновременно использоваться разные способы.

Архитектура Subversion

Рис. 6. Архитектура Subversion

На одной стороне схемы изображено хранилище Subversion, в котором хранится информация с версиями. На противоположной стороне показана программа-клиент Subversion, которая управляет локальными отражениями различных фрагментов этих данных (также называемыми «рабочими копиями»). Между этими сторонами проложены различные маршруты, проходящие через разные слои доступа к хранилищу. Некоторые из этих маршрутов используют компьютерные сети и сетевые сервера, чтобы достичь хранилища, в то время как другие маршруты в сети не нуждаются и ведут к хранилищу напрямую.

Компоненты Subversion

Установленная Subversion имеет несколько компонентов. Ниже приводится краткий обзор того, что вы получаете.

svn

Клиент с интерфейсом командной строки.

svnversion

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

svnlook

Инструмент прямого управления хранилищем Subversion.

svnadmin

Инструмент для создания, настройки или восстановления хранилища Subversion.

svndumpfilter

Программа для фильтрации дамповых потоков хранилища Subversion.

mod_dav_svn

Подключаемый модуль для HTTP-сервера Apache, использующийся для предоставления сетевого доступа к вашему хранилищу.

svnserve

Собственный отдельный сервер, запускаемый как процесс-демон и доступный посредством SSH; еще один способ для предоставления сетевого доступа к хранилищу.

svnsync

Программа для последовательного зеркалирования одного хранилища в другое через сеть.

Рабочая копия

Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория. Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.

Рабочая копия является самодостаточной в том смысле, что Subversion не хранит каких-либо данных, относящихся к рабочей копии, вне её. Поэтому, имея одну рабочую копию, можно сделать ещё несколько копий без затрат сетевого трафика. В служебных директориях рабочей копии, помимо прочего, хранится (в директориях .svn/text-base/) так называемая чистая копия (англ. pristine copy) — файлы рабочей копии в неизменённом виде, как они были извлечены из хранилища. Наличие чистой копии позволяет быстро и без обращения к хранилищу выполнять операции просмотра и отката локальных изменений.

Транзакции

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

Атомарность. В Subversion фиксации изменений атомарны (англ. atomic commits). Это значит, что если изменения сделаны в нескольких файлах и директориях, то они фиксируются как единая транзакция, порождая при этом одну ревизию. Система гарантирует, что либо в хранилище попадают все изменения, либо (при неудачной фиксации) состояние хранилища не изменяется, ревизия не создаётся.

Изоляция. С точки зрения пользователей не существует состояния хранилища «в середине» транзакции. Если один пользователь фиксирует изменения множества файлов единой транзакцией, то другие пользователи не могут увидеть такого состояния хранилища, в котором часть файлов зафиксирована, а часть — не зафиксирована. Хранилище мгновенно переходит из состояния до транзакции в состояние после транзакции, поскольку новая головная ревизия появляется только когда транзакция уже завершена, а до этого видна только предыдущая ревизия. Другими словами, невозможно увидеть состояние хранилища «между» ревизиями.

Структура проекта в хранилище

Subversion не накладывает каких-либо ограничений на структуру директорий в файловой системе хранилища, она может быть какой угодно в рамках правил именования объектов файловой системы. Тем не менее, существуют некоторые общепринятые «правила хорошего тона». В простейшем случае в корневой директории файловой системы имеются как минимум три директории:

/branches

/tags

/trunk

Директория /trunk содержит основную линию разработки проекта, /branches содержит все ветви, /tags содержит все метки. Такая структура удобна для хранилища, содержащего только один проект. Если проектов несколько, то более удобна следующая структура:

/project1

/branches

/tags

/trunk

/project2

/branches

/tags

/trunk

То есть в корневой директории находятся директории проектов, и в каждом из них есть свои trunk, branches, tags, относящиеся только к этому проекту. Описанные структуры директорий хранилища являются лишь примерами, на практике хранилище можно организовать таким способом, который оптимально подходит в данном конкретном случае.

Другим способом хранения нескольких проектов является создание нескольких хранилищ. В разных хранилищах следует располагать проекты, которые никак не связаны между собой, поскольку между хранилищами нельзя будет выполнить операции копирования, перемещения и слияния. Несколько хранилищ можно при необходимости объединить в одно с сохранением истории ревизий.

Использование Subversion

Простейший рабочий цикл

Простейший цикл работы с Subversion включает следующие этапы:

Создание рабочей копии (svn checkout).

Изменения файлов и директорий в рабочей копии. В изменении файлов Subversion никак не задействован — изменения производятся программами, предназначенными для этого (текстовые редакторы, средства разработки и т. п.).

Для файловых операций, если нужно удалить, переименовать, переместить или скопировать файл или директорию в рабочей копии, необходимо использовать средства Subversion (команды svn delete, svn move, svn copy);
просмотр локальных (еще не зафиксированных) изменений в рабочей копии осуществляется командой (svn diff);
любые локальные изменения, если они признаны неудачными, можно откатить (svn revert).

Фиксация изменений (svn commit)

Регулярное обновление рабочей копии последними зафиксированными изменениями (svn update)

Ветвление

Рис. 7. Ветвление Subversion

На рисунке 7 условно показан пример эволюции ветвей в хранилище. Зелёным цветом показана основная линия разработки проекта (англ. mainline, trunk), жёлтым — ветви, синим — метки, пурпурным — ветвь, разработка которой прекращена. Красными стрелками показаны слияния изменений.

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

Создание ветвей

Новая ветвь (а также метка) создаётся командой svn copy, которая создаёт в хранилище копию с наследованием истории ревизий источника (операция A+). Для создания ветвей всегда следует использовать «удаленную» форму команды svn copy.

Полученная копия будет ветвью (или меткой, в зависимости от способа работы с ней). В дальнейшем изменения, сделанные на ветви, могут быть внесены в источник, из которого была создана эта ветвь, такое распространение изменений называется слияние (англ. merge).

Операции копирования в Subversion дешёвые (англ. cheap copy), то есть требуют небольшого фиксированного количества времени и дискового пространства. Хранилище спроектировано таким образом, что при любом копировании происходит не дублирование данных, а создание ссылки на источник (аналогично жёсткой ссылке), однако этот механизм чисто внутренний — с точки зрения пользователя происходит именно создание копии. Благодаря высокой эффективности ветвей их можно создавать настолько часто, насколько это необходимо.

Слияние

Копирование изменений между ветвями

Слияние в Subversion — это применение к ветви набора изменений, сделанных на другой ветви. Для осуществления слияния необходимо использовать команду svn merge — она применяет набор изменений к рабочей копии; затем нужно зафиксировать внесенные изменения (svn commit).

Другие применения команды svn merge

Команду svn merge можно использовать не только для слияния. Фактически команда производит внесение в рабочую копию изменений, равных разнице между двумя директориями или файлами в хранилище, поэтому svn merge является универсальным средством для переноса изменений. Можно привести такие примеры использования команды svn merge:

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

Subversion и CVS

Сравнение

Ниже приведено сравнение параметров систем Subversion и CVS, так как Subversion позиционируется именно как улучшение CVS. Приведено сравнение только по тем параметрам, по которым эти системы отличаются. В целом Subversion превосходит CVS по всем параметрам, кроме поддержки меток в общепринятом смысле (то есть меток, адресующих объекты файловой системы).

Таблица 1. Сравнение Subversion с CVS

Параметр	Subversion	CVS
Возможности
Директории	Отслеживает версии не только файлов, но и директорий.	Версии директорий не отслеживаются, то есть структура директорий одна и та же (та, которая существует в хранилище на данный момент) для всех ревизий и всех веток. Если изменить структуру директорий, то при извлечении старых состояний получаем правильные (старые) ревизии файлов, но в неправильной (существующей на момент извлечения) структуре директорий.
Транзакции	Атомарность многофайловых фиксаций.	Атомарность только на уровне однофайловых фиксаций. Фактически фиксация изменений в нескольких файлах разбивается на последовательность фиксаций изменений отдельных файлов. Если такая последовательность фиксаций прервана, то часть файлов остается зафиксированной, часть - не зафиксированной.
Наборы изменений	Наборы изменений (англ. changeset) поддерживаются.	Наборы изменений не поддерживаются.
Модификации имён файлов	Поддерживает копирование, перемещение и переименование файлов и директорий без потери истории изменений.	При копировании, перемещении и переименовании файлов файл с новым именем не имеет никакой истории, то есть связь со старым именем и его историей версий полностью теряется. То же самое для файлов внутри директории при модификации её имени.
Свойства (properties)	С каждым файлом и директорией может быть связан произвольный набор свойств, состоящих из названия и значения. Свойства тоже находятся под управлением версиями.	Свойства не поддерживаются
Блокировки	Поддерживается необязательная блокировка файлов (начиная с версии 1.2).	Блокировки не поддерживаются, но есть похожий механизм, называемый слежение
Ветви	Ветви (branch) реализованы в пространстве путей. Это значит, что для создания ветви производится копирование директории (копия и будет ветвью). Создание таких копий — быстрая и не ресурсоёмкая операция, потому что данные не дублируются, вместо этого фиксируется новая версия, отличающаяся от предыдущей лишь расположением файлов.	Ветви реализованы в «третьем измерении». Это значит, что файл на ветви адресуется тремя параметрами: путём в файловой системе, ревизией (или другим способом указания ревизии, например, временем), именем ветви.
Метки	Нет меток (tag), как таковых. Вместо них используется иерархия директорий — для метки создаётся отдельная директория (как и для ветви). Метка — это ветвь, в которой по договоренности больше не делают изменений. Метка является копией помеченного состояния файлов и директорий.	Метки поддерживаются. Метка адресует помеченное состояние файлов.
Эффективность
Клиент-серверный обмен	При любых обновлениях версий между клиентом и сервером передаются только различия между файлами, что может существенно уменьшить сетевой трафик.	С сервера к клиенту передаются различия, с клиента на сервер объект передаётся полностью
Двоичные файлы	Одинаково эффективно работает как с текстовыми, так и с двоичными файлами.	Работа с двоичными файлами менее эффективна: каждая новая версия сохраняется в хранилище полностью.
Создание ветвей и меток	Требуется небольшое фиксированное количество времени и дискового пространства.	Затраты времени велики (зависят от количества задействованных файлов). Имена ветвей и меток хранятся избыточно (во всех задействованных файлах).
Накладные расходы в рабочей копии	В служебных директориях рабочей копии хранится чистая копия. Поэтому операции просмотра и отката локальных изменений выполняются быстро (без обращения к хранилищу), однако размер рабочей копии на диске примерно в два раза больше, чем размер самих данных.	Чистая копия не хранится, размер рабочей копии примерно равен размеру данных. Вследствие этого операции просмотра и отката локальных изменений требуют доступа к хранилищу и выполняются медленно.
Расход памяти на сервере	Меньше	Больше.

Blog