Subversion

Subversion (SVN)  — свободная централизованная система управления версиями.

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

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

В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)».

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

История

Разработка Subversion была начата в 2000 году по инициативе и при финансовой поддержке CollabNet, Inc. Инициаторы проекта хотели создать свободную систему управления версиями, в основном похожую на CVS, но лишённую её ошибок и неудобств. В то время не существовало лучших программ этого класса со свободной лицензией, CVS была стандартом де-факто среди разработчиков свободного программного обеспечения. Выбрав её за основу, разработчики Subversion надеялись упростить разработку за счёт использования уже проверенных концепций и в то же время облегчить переход на новую систему многочисленным пользователям CVS.

31 августа 2001 года, спустя четырнадцать месяцев с начала работы, команда разработчиков перешла с CVS на Subversion для управления собственным исходным кодом — Subversion стала «самодостаточной».

23 февраля 2004 года вышел релиз 1.0.0. К этому времени Subversion уже использовалась примерно на 1400 серверах с открытым доступом.

29 сентября 2004 года появился релиз 1.1.0. Среди основных нововведений — новый формат хранилища на основе обычных файлов (FSFS), в дополнение к существовавшему ранее (с использованием Berkeley DB).

В релизе 1.2.0 (21 мая 2005 г.) была добавлена возможность блокировки файлов. Это позволило улучшить поддержку клиентов WebDAV/DeltaV, в том числе, реализовать автоматическое создание новых версий при редактировании файлов с помощью таких клиентов. Начиная с этого релиза Subversion по умолчанию использует FSFS для новых хранилищ.

Релиз 1.4.0 (10 сентября 2006) поддерживает работу с BerkeleyDB 4.4 и может использовать её функции самовосстановления. Ранее при сбоях Subversion хранилище, использующее BerkeleyDB, могло остаться в «заклиненном» состоянии и требовалось вмешательство администратора для восстановления работы системы (при использовании FSFS этой проблемы нет).

В релизе 1.5.0 (19 июня 2008) сделано множество улучшений, самым значительным из которых является базовая поддержка отслеживания слияний (англ. merge tracking). Эта возможность делает процесс слияния в Subversion более простым и надежным.

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

Возможности

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

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

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

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

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

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

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

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). Для доступа к одному и тому же репозиторию могут одновременно использоваться разные способы.

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

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

Рисунок 1. Двумерное представление файловой системы в Subversion

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

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

Имена файлов

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

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

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

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

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

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

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

Оперативная и cтержневая ревизии

Рисунок 2. Указание стержневой ревизии

Номер ревизии используется в двух различных контекстах:

• Оперативная ревизия (англ. operative revision)
• Стержневая ревизия (англ. peg revision)

Ревизия называется оперативной, если она указывается как ревизия или диапазон ревизий, к которому должна быть применена команда, например:

svn log -r 199:230 http://...

В данном примере выполняется команда log для диапазона ревизий 199:230, который и является диапазоном оперативных ревизий.

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

svn log -r 29:33 http://.../bar.txt

В команде указан диапазон оперативных ревизий (29:33), но области, выделенные на рисунке голубым и зеленым фоном, в равной степени можно считать историей файла /bar.txt в диапазоне ревизий 29:33. В подобных случаях необходимо указывать еще и стержневую ревизию для разрешения неоднозначности. Стержневая ревизия — это номер ревизии, указанный после URL объекта файловой системы. Между URL и номером стержневой ревизии ставится символ «@», то есть используется запись вида URL@номер. URL со стержневой ревизией представляет собой полный идентификатор (имя+ревизия) объекта в двумерной файловой системе. При выполнении команды используется та единственная цепочка состояний, на которую указывает URL со стержневой ревизией. В приведенном ниже примере первая команда выведет историю, выделенную на рисунке голубым фоном, а вторая — историю, выделенную зеленым фоном:

svn log -r 29:33 .../file.txt@32
svn log -r 29:33 .../bar.txt@34

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

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

• Добавление (A). Добавление объекта в файловую систему. Добавленный объект не имеет истории ревизий. Пример на рисунке:

• файл /main.c был добавлен в ревизии 27.

• Модификация (M). Модификация объекта, например, изменение содержимого файла или изменение свойств файла или директории. Пример на рисунке:

• файл /main.c был модифицирован в ревизии 28.

• Удаление (D). Удаление файла с головной и последующих ревизий. При этом файл остаётся в предыдущих ревизиях. Пример на рисунке:

• файл /main.c был удалён в ревизии 30.

• Добавление с историей (A+). Представляет собой копирование объекта внутри файловой системы хранилища, то есть объект имя_источника@ревизия_источника копируется в имя_копии@HEAD. Скопированный объект наследует от источника историю ревизий до момента копирования (наследование истории показано на рисунке пунктирными связями). Примеры на рисунке:

• в ревизии 29 директория /tags/R1 была скопирована с директории /trunk@27.
• в ревизии 31 файл /main.c был скопирован с /main.c@29, то есть с более ранней ревизии самого себя. Таким образом, произведено восстановление ранее удалённого (в ревизии 30) файла с сохранением истории ревизий.

• Замена (R+). Имеет место в случае, когда в одной ревизии произведено и удаление объекта (D), и добавление с историей (A+) объекта с тем же самым именем. Хотя имя при операции замены остается неизменным, Subversion рассматривает объект до и после замены как два различных объекта с различными историями ревизий (история старого заканчивается в точке замены, история нового наследуется от источника копирования и продолжается далее). Пример на рисунке:

• в ревизии 30 файл /file.txt был заменен: старый файл /file.txt удален, а новый файл с тем же именем скопирован с файла /bar.txt@29.

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

Рабочая копия — это созданная клиентской программой 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, относящиеся только к этому проекту. Описанные структуры директорий хранилища являются лишь примерами, на практике хранилище можно организовать таким способом, который оптимально подходит в данном конкретном случае.

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

Ветви

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

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

Рисунок 3. Пример эволюции ветвей в Subversion

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

Типовые приемы использования ветвей

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

• Релизная ветвь (англ. release branch). Во время выпуска релиза программного обеспечения недопустимо публиковать потенциально дестабилизирующие изменения исходного кода, поэтому перед выпуском релиза обычно создается релизная ветвь, в которую публикуются только исправления ошибок. Все остальные изменения публикуются в стволовую ветвь. Таким образом, стабильность кода на релизной ветви не нарушается и релиз выпускается из кода этой ветви. В дальнейшем можно путем слияния перенести исправления, сделанные на релизной ветви, и на стволовую ветвь.
• Функциональная ветвь (англ. functional branch).

Метки

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

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

Достоинства:

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

Недостатки:

• Для объекта файловой системы очень трудно узнать, в какие метки он вошёл.
• Если права доступа установлены индивидуально для директорий, то метка эти права не наследует.
• Помеченные данные могут быть изменены.
• Публикация изменений в рабочей копии, созданной из метки, изменит саму метку, а не те данные, которые были помечены. Вместо этого нужно создавать рабочую копию из того, что является источником этой метки.

Свойства (properties)

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

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

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

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

svn:executable 

Делает файл исполняемым (для рабочих копий под операционными системами семейства UNIX).

svn:mime-type 

Хранит MIME-тип файла. Влияет на способ работы команд, показывающих разницу файлов, а также объединяющих изменения (merging).

svn:keywords 

Список ключевых слов (англ. keywords), которые будут заменены в файле соответствующими значениями. Чтобы замена произошла, ключевое слово должно присутствовать в файле в виде $keyword$. Используется для того, чтобы автоматически обновлять в файле значения, меняющиеся от версии к версии (например, номер ревизии).

svn:eol-style 

Определяет правило преобразования символов конца строки (англ. end-of-line, EOL) в текстовом файле. Используется в случаях, когда файл должен иметь конкретный тип символов EOL. Обычно используется «native» — при этом тип символов конца строки соответствует принятому в той операционной системе, в которой происходит создание рабочей копии.

svn:needs-lock 

Означает, что при извлечении из хранилища файл будет доступен только для чтения. Это свойство предназначено для использования совместно с механизмом блокировки. Запрет записи в файл является напоминанием того, что надо получить блокировку на этот файл, прежде чем его редактировать: при получении блокировки клиентская программа Subversion автоматически делает файл доступным для записи (снятие блокировки снова делает файл защищенным от модификаций). Блокировки могут быть использованы и без установки этого свойства. Однако делать это не рекомендуется, так как существует риск того, что другой пользователь может начать редактировать заблокированный файл, и это обнаружится только при публикации изменений.

svn:special 

Свойство не предназначено для установки или модификации пользователями. В настоящее время используется для хранения символьных ссылок в репозитории. Когда символьная ссылка добавляется в репозиторий, в репозитории создаётся файл с установленным свойством svn:special. Когда этот файл извлекается в UNIX-подобной системе, клиентская программа Subversion преобразует его обратно в ссылку.

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

svn:ignore 

Список шаблонов имён файлов и директорий, которые клиентская программа Subversion будет игнорировать в данной директории. Это свойство аналогично файлу .cvsignore в CVS. Как правило, свойство настраивается таким образом, чтобы клиентская программа «не видела» файлы и директории, которые автоматически создаются различными программами и не должны быть версионированы (например, объектные файлы, временные файлы и т. п.). Действие этого свойства не распространяется на поддиректории.

svn:externals 

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

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

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

svn:date 

Дата и время создания ревизии.

svn:author 

Имя пользователя, который опубликовал изменения, вошедшие в эту ревизию.

svn:log 

Описание изменений, опубликованных в этой ревизии (текст, введенный пользователем при публикации изменений).

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

Subversion и CVS

Сравнение

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

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

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

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

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

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

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

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

svn delete <старое имя>
svn add <новое имя>

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

svn move <старое имя> <новое имя>

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

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

Адресация состояния хранилища

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

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

Слои

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

Fs 

Самый низкий уровень; реализует версионированную файловую систему, которая и хранит данные.

Repos 

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

mod_dav_svn 

Обеспечивает WebDAV/Delta-V-доступ через Apache 2.

Ra 

Реализует доступ к хранилищу (и локальный, и удалённый). Начиная с этого слоя на хранилище можно ссылаться по URL, то есть

• file:///path/ для локального доступа,
• http://host/path/ или https://host/path/ для доступа через WebDAV , или
• svn://host/path/ или svn+ssh://host/path/ для доступа через протокол SVN.

Client, Wc 

Самый высокий уровень. Абстрагирует доступ к хранилищу и обеспечивает выполнение типичных задач клиента, таких, как аутентификация пользователя или сравнение версий. Client использует библиотеку Wc для управления локальной рабочей копией.

Недостатки

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

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

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

См. также

• TortoiseSVN
• USVN
• AnkhSVN

Ссылки

• Официальный сайт (англ.)
• Книга «Управление версиями в Subversion», Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато
• Ссылки на официальном сайте (англ.)
• Статьи на CollabNet Subversion Community (англ.)
• Merging and branching in Subversion 1.5 (англ.) By John Ferguson Smart, JavaWorld.com.
• Version Control and «the 80 %» (англ.) Бен Коллинз-Сассман (создатель Subversion) о будущем Subversion и о распределённых системах. Русский перевод этой статьи.

Публичные хранилища SVN

• http://sourceforge.net — SourceForge.net, наиболее популярный хостинг свободных проектов.
• http://svn.berlios.de/wsvn — BerliOS
• Google Code
• http://assembla.com
• Cписок на официальном сайте Subversion

В статье использованы материалы из Википедии.