Содержание


Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Часть 2. Subversion - установка и администрирование сервера

Comments

Серия контента:

Этот контент является частью # из серии # статей: Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Следите за выходом новых статей этой серии.

Сам термин администрирование часто отпугивает возможной масштабностью задачи (возьмем к примеру администрирование Oracle, которым на крупных предприятиях занимаются целые сектора).Основная цель статьи — показать пользователям, решившим поддерживать контроль версий своей разработки, что задача администрирования Subversion:

  • посильна для любого программиста;
  • не требует значительных временных затрат;
  • требует организованности и методичности.

Одним из важнейших преимуществ Subversion является многоплатформенность, полная совместимость серверных и клиентских частей, работающих на разных платформах, удивительная простота установки серверной и клиентской частей и легкость администрирования. В статье будут рассматриваться вопросы в аспекте Linux (на примере OpenSUSE 11.2) и Windows XP.

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

К чему сводится задача администрирования

Если говорить в общем, то любую систему можно свести к трем основным функциям: управление, исполнение и создание условий для исполнения. Спорить по поводу терминологии нет смысла, но суть совершенно понятна. Должен быть тот кто организует работу, определяет обязанности, распределяет функции, корректирует результаты, планирует действия на перспективу и тот кто конкретно исполняет работу, результатом которой будет конкретная материальная выгода (в нашем случае работающая программа, информационная система, сайт и так далее). Администратор на первый взгляд стоит в стороне от непосредственной работы. Его функции незаметны (за исключением распределения прав доступа), но без грамотного администрирования системы после нескольких даже лет безбедной работы наступает расплата — крах системы. Что же мы должны получить в результате администрирования системы контроля версий (в какой то мере это вполне справедливо и для баз данных, сетей и так далее)?

Перечислим основные функции, которые далее будут рассмотрены подробнее:

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

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

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

Транзакция (transaction) — последовательность различный действий, выполняемых Subversion, в результате которых хранилище переходит из одного состояния к другому. Незавершенная транзакция может привести к нарушению целостности данных в хранилище.

Способы хранения данных в хранилище (Repository Data Stores) — в настоящее время данные могут храниться в двух форматах база данных Беркли (Berkeley DB) и виртуальная файловая система (FSFS) на основе родной файловой системы операционной системы. Исторически первой использовалась база данных Беркли, но из-за высокой чувствительности к прерываниям и возникающих из-за этого сбоев с 2004 года используется FSFS. В настоящее время FSFS устанавливается по умолчанию.

Где взять Subversion?

Практически все, что необходимо для работы с Subversion можно получить на сайте http://subversion.tigris.org (EN). Там можно или загрузить дистрибутивы или найти ссылку на сайты, где они находятся. Subversion достаточно устоявшаяся система и небольшое отставание версий в дистрибутивах операционных систем на мой взгляд не критично, хотя никто не мешает отслеживать появление новых версий.

Что касается Linux, то Subversion входит основной репозиторий практически всех дистрибутивов и устанавливается стандартным путем.

Утилиты администратора

Обращаю внимание, что все задачи администрирования могут запускаться только с компьютера, на котором располагается хранилище (ссылка через URL не может быть использована, как это принято при работе с клиентом Subversion). Удаленное управление возможно только средствами туннелирования (например OpenSSH), но здесь мы все равно работаем как бы на самом компьютере с хранилищем.

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

  • svnadmin — основная утилита, которая позволяет собственно создавать новый репозиторий, снимать дампы, выполнять горячее копирование, загружать дампы, следить за блокировками в репозитории, удалять блокировки, отслеживать и удалять неподтвержденные транзакции и проверять правильность данных в репозитории;
  • svnlook — используется исключительно для просмотра разнообразных свойств хранилища (имя автора, содержимое файла, измененные пути, различия между файлами, измененные директории и др.);
  • svndumpfilter — позволяет проводить фильтрацию дампов на основе заданных критериев (реально используется крайне редко);
  • Обязательным параметром каждой утилиты является help. Следует быть крайне аккуратным при выборе порядка слов в команде, так команда $svnadmin create help (вместо $svn help create) вместо справки создаст хранилище в директории ./help)

Инсталляция

OpenSUSE 11.2

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

Установка через YaST2

Запускаем цент управления через меню Компьютер — YaST или из консоли командой

# /sbin/yast2

После запуска выбираем в разделе Программное обеспечение Управление программным обеспечением. В открывшемся окне выбираем вкладку Группы RPM и находим группу пакетов Development/Tools/Version Control, выбираем Subversion и запускаем установку.

Установка через YaST2 (псевдографика)

Если нет возможности использовать графический интерфейс, но хочется получить определенный уровень удобств, то можно воспользоваться командой

# /sbin/yast

и все те же действия повторить в режиме псевдографики.

Установка в консольном режиме

Для тех, кто предпочитает работу в консольном режиме все еще проще, достаточно под пользователем root выполнить:

zypper install subversion

Информацию о способах установки программы в других unix-подобных системах (например, в различных дистрибутивах GNU/Linux) можно получить в соответствующем разделе документации по этим ОС.

Создание нового репозитория

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

Де факто в правилах хорошего тона принято несколько стандартных способов организации хранилища. Как правило, это директория trunk, в которой находится «основная линия» разработки, директория branches для хранения веток (параллельных разработок, в которых прорабатываются какие то варианты решения) и директория tags для хранения меток. Если хранилище содержит один проект, то создают три директории верхнего уровня, например:

/myrepos/trunk
/myrepos/branches
/myrepos/tags

Если хранилище в предназначено для нескольких проектов (например argo, archiv и booking), то под каждый из проектов желательно выделить по три директории и дерево проектов в хранилище будет выглядеть следующим образом:

/myrepos/argo/trunk
/myrepos/argo/branches
/myrepos/argo/tags
/myrepos/archiv/trunk
/myrepos/archiv/branches
/myrepos/archiv/tags
/myrepos/booking/trunk
/myrepos/booking/branches
/myrepos/booking/tags

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

$ svnadmin create ./myrepos

В результате будет создан репозиторий в директории ./myrepos. Если посмотреть, что произошло после создания, то мы увидим следующее:

$cd myrepos
$ls -l
итого 8
drwxr-xr-x 2 alexib users 128 Янв 15 14:22 conf
drwxr-sr-x 6 alexib users 448 Янв 15 14:22 db
-r--r--r-- 1 alexib users   2 Янв 15 14:22 format
drwxr-xr-x 2 alexib users 360 Янв 15 14:22 hooks
drwxr-xr-x 2 alexib users 104 Янв 15 14:22 locks
-rw-r--r-- 1 alexib users 229 Янв 15 14:22

Появилось 4 новых каталога, которые содержат следующую информацию:

  • conf — директория в которой хранятся конфигурационные файлы репозитория;
  • db — вот здесь собственно и хранятся все ревизии поддерживаемых проектов;
  • hooks — содержит так называемые hook-скрипты (первоначально это просто шаблоны), которые на самом деле являются типичными обработчиками событий и с их помощью можно управлять реакцией сервера на определенные события;
  • locks — здесь хранится информация о блокировках.

Кроме того появились и два файла:

  • format — содержит единственное число, соответствующее версии внутреннего формата хранения данных в репозитории.
  • README.txt — здесь просто находится сообщение, что вы в репозитории Subversion, а за дополнительной информацией можно обратиться на сайт http://subversion.tigris.org/ (EN).

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

Резервное копирование и восстановление данных

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

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

Резервное копирование базируются на двух командах.

svnadmin dump

Выводит содержимое файловой системы на стандартное устройство вывода в переносимый формат, отправляя ошибки в стандартный поток ошибок. Команда выводит ревизии от LOWER(первой) до UPPER(последней). Если ревизии не указаны, то происходит вывод всего дерева. Если указан только параметр LOWER, то происходит вывод данного дерева ревизий.

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

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

Svnadmin hotcopy

Синтаксис

svnadmin hotcopy REPOS_PATH NEW_REPOS_PATH

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

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

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

Вместо самостоятельного выполнения действий по резервному копированию можно воспользоваться наработками команды разработчиков Subversion. В группе пакетов Development/Tools/Version Control размещен ряд пакетов для резервного копирования. С заданным путем к хранилищу и местом резервного копирования, скрипт hot-backup.py – (базируется на команде svnadmin hotcopy) - выполнит необходимые шаги для резервного копирования текущего хранилища, не требуя запрета общественный доступа к хранилищу, а потом удалит мертвые лог-файлы Berkeley из вашего текущего хранилища.

К резервному копированию следует подходить серьезно. Оно должно выполняться регулярно. Частота копирования определяется интенсивностью фиксаций изменений участниками проекта.

Лучшее решение задачи - добавление hot-backup.py к программе планировщику (например, cron на системах Unix) и в этом случае копирование будет привязано к определенным дням недели и времени.

Если фиксации происходят достаточно редко (интенсивная фаза работы над проектом завершена и изменения происходят по мере фиксации и исправления оставшихся ошибок), то регулярное копирование приведет к дублированию информации. В этом случае предпочтительнее решения с использованием hook-скрипта, выполняемого после фиксации (hot-backup.py), который затем будет вызывать резервное копирование хранилища с каждой новой созданной ревизией. Для этого надо добавить следующее к hooks/post-commitscript в директории текущего хранилища:

(cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &)

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

У обоих методов резервного копирования есть свои преимущества. Самым простым является, несомненно, создание полной резервной копии, которая всегда будет идеальной рабочей копией вашего хранилища. К сожалению, каждая из копий будет «съедать» столько же места на диске, сколько и текущее хранилище.

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

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

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

Часто, лучший способ резервного копирования хранилища - это комбинация различных способов.

Отслеживание состояния хранилища с помощью утилиты Svnlook

Svnlook это утилита командной строки для проверки разнообразных свойств репозитория Subversion. Команда не производит никаких изменений с репозиторием – она используется только для просмотра. Svnlook обычно используется с hook-скриптами репозитория, но может оказаться полезной и администратору хранилища для целевых проверок.

Поскольку svnlook работает через прямой доступ к хранилищу (как и svnadmin)), доступ к репозиторию происходит через путь, а не URL.

Если ревизия или транзакция не установлены, то svnlook по умолчанию выбирает самую последнюю ревизию из репозитория.

  • svnlook author — Вывод автора.
  • svnlook cat — Вывод содержимого файла.
  • svnlook changed — Вывод путей, которые были изменены.
  • svnlook date — Вывод даты и времени.
  • svnlook diff — Вывод различий измененных файлов и свойств.
  • svnlook dirs-changed — Вывод директорий, которые были изменены.
  • svnlook history — Вывод информации об истории.
  • svnlook lock — Если путь в репозитории заблокирован, то описывает эту блокировку.

Разграничение доступа

Существуют три метода доступа к репозиторию:

  • локальный (file://),
  • svnserve (svn://, svn+ssh://),
  • apache (http://, https://).

При этом работу в локальной сети имитирует метод svn+ssh://, а доступ регламентируется средствами операционной системы.

Для метода svn:// достаточно, чтобы соответствующие полномочия имел псевдо-пользователь subversion, а для http:// - apache2. В последних двух случаях права на чтение/запись в репозиторий определяются не файловой системой, а файлами конфигурации сервера:

svn: /var/lib/subversion/test/conf/svnserve.conf и passwd
apache: /etc/httpd2/conf/addon.d/A.subversion.conf и htaccess/htpasswd

Hook-скрипты

Hook (специальная процедура, отслеживающая появление некоторого события) – аналог метода в объектно-ориентированном программировании и триггера в базах данных. Шаблоны скриптов расположены:

$ ls repos/hooks/
post-commit.tmpl		post-unlock.tmpl	pre-revprop-change.tmpl
post-lock.tmpl			pre-commit.tmpl	pre-unlock.tmpl
post-revprop-change.tmpl	pre-lock.tmpl		start-commit.tmpl

Скрипты написаны на языке Python и активируются следующими событиями:

  • start-commit — запускается до начала транзакции, может быть использован для проверки прав.
  • pre-commit — запускается в конце транзакции, но до фиксации, может использоваться для проверки данных.
  • post-commit — запускается после транзакции, может быть использовано для отправки e-mail или для резервирования хранилища.
  • pre-revprop-change — запускается до изменений в ревизии, могут быть использованы для проверки доступа.
  • post-revprop-change — запускается после изменений в ревизии, могут быть использованы для отправки e-mail или для резервирования изменений.

Скрипты post-lock, post-unlock, pre-lock и pre-unlock, срабатывают при блокировке. На практике используются крайне редко.

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=551931
ArticleTitle=Организация совместной разработки ПО на базе SVN+DocBook+Mantis: Часть 2. Subversion - установка и администрирование сервера
publish-date=10182010