Subversion:

Subversion разработана специально для замены устаревшей системы CVS^[2]^[3], самой распространённой открытой системы управления версиям. Subversion обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и свободна от ряда её недостатков.

История

Разработка Subversion была начата в 2000 году как попытка создать свободную систему управления версиями, в основном похожую^[4] на CVS, но свободную от ее ошибок и неудобств. 31 августа 2001 года, спустя четырнадцать месяцев с начала работы, команда разработчиков перешла с CVS на Subversion для управления версиями собственного исходного кода — Subversion стала «самодостаточной».^[5]

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

Возможности

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

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

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

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

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

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

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

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

Основные концепции

Файловая система

С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. Объекты в хранилище (файлы и каталоги) идентифицируются двумя «координатами»: именем и номером ревизии. Для однозначной адресации объекта необходимо указание обоих параметров. При необходимости указания на конкретную ревизию объекта используется запись вида: имя@ревизия, например, /main.c@29 — файл /main.c в ревизии 29. Такое указание ревизии, используемое для уточнения имени, называется стержневая ревизия (англ. peg revision).

На рисунке показано графическое представление файловой системы: вертикальная ось соответствует множеству имен, горизонтальная — множеству ревизий. Другими словами, хранилище представляет собой массив мгновенных снимков (ревизий) дерева файлов и каталогов. Каждый такой снимок — обычная (одномерная) файловая система.

Имена файлов

Имя объекта файловой системы в Subversion образуется по тем же правилам, что и в UNIX-подобных операционных системах: существует только один корневой каталог, элементы пути разделяются косой чертой «/». Объектами файловой системы являются файлы и каталоги (а также символические ссылки, которые эмулируются из обычных файлов путем установки атрибута svn:special).

Номера ревизий

Номер ревизии в Subversion — это неотрицательное целое число, адресующее номер состояния хранилища в процессе изменения содержащихся в нём данных. Каждая успешная публикация изменений порождает ровно одну новую ревизию в хранилище, то есть N-я ревизия — это состояние хранилища после N-й публикации.

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

Номер ревизии является аналогом времени в том смысле, что меньшие номера ревизий соответствуют более ранним состояниям хранилища, а бо́льшие — поздним:

Ревизию можно рассматривать как некую временну́ю отметку в истории хранилища. Более того, с каждым номером ревизии связано абсолютное значение времени, когда эта ревизия была сделана (свойство svn:date). Однако указание номера ревизии удобнее, чем указание времени, так как нет путаницы с часовыми поясами, запись номера короче и номер ревизии не может быть изменен.

Операции над файловой системой

Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции^[7] (смотри также рисунок). В скобках указано краткое именование операции в обозначениях команды svn status.

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

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

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

Транзакции

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

Ветви и метки

Ветви

Subversion использует «файловую» модель (такую же, как и в Perforce^[8]) для реализации ветвей и меток. Новая ветвь или метка создается командой svn copy, которая создает в хранилище копию источника с сохранением истории ревизий (A+). Полученная копия будет ветвью (или меткой, в зависимости от способа работы с ней). В дальнейшем изменения, сделанные на ветви, могут быть перенесены на источник, от которого была создана эта ветвь, такое распространение изменений называется слияние (англ. merge)

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

Метки

Создание метки также производится командой svn copy, то есть технически не отличается от создания ветви. Отличие только в способе использования: предполагается, что никто не будет изменять данные в метке (публиковать в нее изменения). Например, на рисунке 1 метка создана в ревизии 29: каталог /trunk из ревизии 27 скопирован под именем /tags/R1. Теперь, если не изменять данные в каталоге /tags/R1, то он навсегда останется точной копией каталога /trunk@27, то есть будет меткой.

Концепция меток, используемая в Subversion, отличается от концепции меток в других системах управления версиями. Метки-копии в Subversion имеют свои достоинства и недостатки:

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

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

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

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

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

Свойства (properties)

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

Свойства объектов файловой системы

Каждому файлу или директории в хранилище может быть присвоен набор свойств. Изменения свойств сохраняются в истории также, как и изменения в файловой системе. Пользователи могут устанавливать свойства с любыми именами; существует также предопределенный набор служебных свойств, которые используются клиентской программой Subversion (имена служебных свойств имеют префикс 'svn:').

Свойства файлов

Свойства директорий

Свойства ревизий

Второй тип объектов, для которых существуют свойства — это сами ревизии. В этом случае имена свойств также могут быть любыми; некоторые свойства с префиксом «svn:» имеют специальное значение. Отличие свойств ревизий от свойств объектов файловой системы в том, что для первых понятие истории версий не применимо (поскольку конкретное значение свойства приписано одной ревизии). Другими словами, свойства ревизий можно изменить, но старое значение при этом теряется.

Subversion и CVS

Сравнение

Ниже приведено сравнение параметров систем Subversion и CVS, так как Subversion позиционируется именно как конкурент CVS. Приведено сравнение только по тем параметрам, по которым эти системы отличаются.

Миграция с CVS на Subversion

Преобразование репозитория

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

Отличия в использовании

Переименование

Пользователи, перешедшие с CVS на Subversion, часто выполняют переименование файлов и каталогов неправильным способом. В CVS не существует иного способа изменения имени, кроме как удалить объект со старым именем и добавить объект с новым именем. Аналогичные (неправильные!) действия в Subversion выполняются парой команд (или аналогичными действиями через графический клиент):

Данный способ переименования неправильный потому, что новый объект, добавленный командой svn add, не имеет истории (поскольку он добавлен как новый), то есть полностью теряется связь со старым именем и его историей ревизий. Правильный способ переименования объектов в Subversion:

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

Все сказанное в равной степени относится и к копированию: следует использовать именно копирование (svn copy), а не добавление нового экземпляра объекта (svn add).

Внутренняя структура

Слои

Управление

USVN — [1] Дружелюбный веб интерфейс для SVN на базе PHP5. Позволяет управлять и конфигурировать репозитарии Subversion.

Позволяет пользователю создавать и управлять проектами без использования командной строки SVN клиента. USVN предоставляет простой, быстрый и мощный механизм управления правами доступа к репозитарию. USVN это проект с открытыми исходными кодами распространяемый по лицензии CeCill (это GPL совместимая лицензия).

Распространённость

По состоянию на 2006 год Subversion уступает по распространённости CVS, однако её можно назвать наиболее популярной альтернативой этой традиционной системе. Многие сообщества разработчиков открытого программного обеспечения перешли на использование Subversion. В их числе такие известные проекты как Apache Software Foundation, KDE, GNOME, GCC, MediaWiki, Python, Samba, Mono и многие другие.

Примечания

↑ Sub- (под-) + version (версия). В то же время, англ. subversion — свержение.
↑ Официальный сайт Subversion
↑ The Risks of Distributed Version Control Бен Коллинз-Сассман
↑ CVS была взята за отправную точку потому, что в то время не существовало лучших программ этого класса со свободной лицензией
↑ "История Subversion", раздел в Управление версиями в Subversion, версия 1.4
↑ Berkeley DB использует блокировки файлов, поэтому она не должна использоваться на (сетевых) файловых системах, которые не поддерживают блокировки
↑ Здесь перечислены операции именно с точки зрения файловой системы хранилища. В рабочей копии действия над объектами несколько иные. Однако изменения в рабочей копии, будучи опубликованными, вызовут в хранилище описанные здесь действия. Например, команда svn move в рабочей копии произведет операции D, A+ в хранилище.
↑ Inter-File Branching in Perforce
↑ Bubble-Up Method
↑ Path-Based Authorization
↑ Структура проектов на C++ с использованием Subversion и Mxx_ru
↑ Хранение сложных проектов в репозитории и установка tag’ов на несколько проектов сразу
↑ Каталог можно переместить прямо в хранилище средствами файловой системы, при этом файлы в нем не потеряют историю. Однако эта модификация подействует на все ревизии и ветви файлов в этом каталоге (поскольку каталоги не имеют версионной информации в CVS)
↑ Такой подход обусловлен тем, что дисковые ресурсы дешевле и доступнее, чем ресурсы сети передачи данных
↑ http://subversion.tigris.org/faq.html#server-requirements

Subversion

Содержание