Просмотр исходного текста страницы Subversion

<!--
{{Карточка программы
| name = Subversion
| screenshot = [[Изображение:Subversion.png|200px]]
| caption = Логотип Subversion
| developer = [http://www.collab.net/ CollabNet, Inc.]
| latest_release_version = 1.5.4
| latest_release_date = [[октябрь]] [[2008]]
| latest_preview_version = 
| latest_preview_date = 
| operating_system = [[GNU/Linux]], {{nobr|[[Microsoft Windows]]}}, {{nobr|[[Mac OS X]]}}, [[FreeBSD]]
| platform =
| genre = [[система управления версиями]]
| license = [http://subversion.tigris.org/license-1.html Аналог] [[Apache license|Apache]]/[[BSD license|BSD]]
| website = [http://subversion.tigris.org/ subversion.tigris.org]
}}
-->
'''Subversion'''<ref>{{lang-en2|[[:en:wiktionary:Sub-|Sub-]]}} (под-) + {{lang-en2|[[:en:wiktionary:version|version]]}} (версия). В то же время, {{lang-en|[[:en:wiktionary:subversion|subversion]]}}&nbsp;— свержение.</ref>&nbsp;('''SVN''')&nbsp;
— [[FSF|свободная]] централизованная [[система управления версиями]].

Subversion разработана специально для замены устаревшей системы [[CVS]]<ref>[http://subversion.tigris.org Официальный сайт Subversion]</ref><ref>[http://blog.red-bean.com/sussman/?p=20 The Risks of Distributed Version Control] Бен Коллинз-Сассман</ref>, распространённой открытой системы управления версиями. Subversion обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и свободна от ряда её недостатков.

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

В [[2007]] году независимая компания [http://www.forrester.com/ Forrester Research], сравнивая преимущества и недостатки различных систем, оценила Subversion как «''единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)''».<ref>{{cite web | url=http://www.collab.net/forrester_wave_report/index.html | title=The Forrester Wave: Software Change and Configuration Management, Q2 2007 | publisher=[[Forrester Research]]}}</ref>

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

== История ==
Разработка Subversion была начата в 2000 году по инициативе и при финансовой поддержке [http://www.collab.net CollabNet, Inc.] Инициаторы проекта хотели создать [[Свободное программное обеспечение|свободную]] систему управления версиями, в основном похожую на CVS, но лишённую её ошибок и неудобств. В то время не существовало лучших программ этого класса со свободной лицензией, CVS была стандартом де-факто среди разработчиков свободного программного обеспечения. Выбрав её за основу, разработчики Subversion надеялись упростить разработку за счёт использования уже проверенных концепций и в то же время облегчить переход на новую систему многочисленным пользователям CVS.<ref>[http://svnbook.red-bean.com/nightly/ru/svn.intro.whatis.html#svn.intro.history История Subversion], раздел в книге «Управление версиями в Subversion, версия 1.4»</ref>

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

23 февраля 2004 года вышел [[Релиз (программное обеспечение)|релиз]] 1.0.0.<ref>[http://svn.collab.net/repos/svn/trunk/CHANGES Список изменений]{{ref-en}}</ref> К этому времени Subversion уже использовалась примерно на 1400 серверах с открытым доступом.<ref>[http://goliath.ecnext.com/coms2/gi_0199-140633/CollabNet-Primary-Sponsor-of-Subversion.html Goliath Business News]</ref>

29 сентября 2004 года появился релиз 1.1.0. Среди основных нововведений — новый формат хранилища на основе обычных файлов (FSFS), в дополнение к существовавшему ранее (с использованием [[Berkeley DB]]).<ref>[http://subversion.tigris.org/svn_1.1_releasenotes.html Subversion 1.1 Release Notes]</ref>

В релизе 1.2.0 (21 мая 2005 г.) была добавлена возможность блокировки файлов.<ref>[http://subversion.tigris.org/svn_1.2_releasenotes.html Subversion 1.2 Release Notes]</ref> Это позволило улучшить поддержку клиентов WebDAV/DeltaV, в том числе, реализовать автоматическое создание новых версий при редактировании файлов с помощью таких клиентов. Начиная с этого релиза Subversion по умолчанию использует FSFS для новых хранилищ.

Релиз 1.4.0 (10 сентября 2006) поддерживает работу с BerkeleyDB 4.4 и может использовать её функции самовосстановления.<ref>[http://subversion.tigris.org/svn_1.4_releasenotes.html Subversion 1.4 Release Notes]</ref> Ранее при сбоях Subversion хранилище, использующее BerkeleyDB, могло остаться в «заклиненном» состоянии и требовалось вмешательство администратора для восстановления работы системы (при использовании FSFS этой проблемы нет).

В релизе 1.5.0 (19 июня 2008) сделано множество улучшений<ref>[http://subversion.tigris.org/svn_1.5_releasenotes.html Subversion 1.5 Release Notes]</ref>, самым значительным из которых является базовая поддержка отслеживания слияний ({{lang-en|merge tracking}}). Эта возможность делает процесс слияния в Subversion более простым и надежным.

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

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

=== Модель работы ===
Subversion&nbsp;— централизованная система (в отличие от распределённых систем, таких, как [[Git]] или [[Mercurial]]), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом [[сервер (аппаратное обеспечение)|сервер]]е.

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

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

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

=== Типы репозиториев ===
Subversion предлагает два варианта организации репозиториев<ref>Термины ''хранилище'' и ''репозиторий'' являются синонимами</ref>. Репозитории первого типа используют для хранения [[база данных|базу данных]] на основе [[Berkeley DB]], репозитории второго типа — в обычных [[файл]]ах специального [[формат файла|формат]]а (доступ к данным организуется с помощью собственных библиотек, без использования сторонних баз данных). Разработчики Subversion часто называют хранилище «файловой системой», поэтому второй тип получил название FSFS, то есть (версионированная) [[файловая система]] ({{lang-en|File System}}), использующая (обычную) файловую систему.

Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации<ref>[http://svnbook.red-bean.com/nightly/ru/svn.reposadmin.basics.html#svn.reposadmin.basics.backends Глава 5. Администрирование хранилища] в книге «Управление версиями в Subversion»</ref> (Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок), каждая из них обладает своими преимуществами и недостатками. Считается, что FSFS легче правильно настроить, она требует меньшего внимания от администратора. Кроме того, до релиза 1.4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном ({{lang-en|wedged}}) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS.

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

* Локальная или сетевая файловая система — используется напрямую клиентской программой Subversion.
* [[WebDAV]]/[[Delta-V|DeltaV]] (поверх [[http]] или [[https]]) с использованием модуля <tt>mod_dav_svn</tt> для [[Apache |Apache 2]].
* Собственный протокол «svn» (порт по умолчанию 3690), используя простой текст или через [[Secure Shell|SSH]].

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

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

=== Файловая система ===
[[Изображение:714px-Subversion 2D filesystem RU.svg.png|509px|thumb|'''Рисунок 1'''. Двумерное представление файловой системы в Subversion]]

С точки зрения пользователя хранилище Subversion представляет собой «двумерную» [[Файловая система|файловую систему]]. Объекты в хранилище ([[Файл|файлы]] и [[Директория (файловая система)|директории]]) идентифицируются двумя «[[Система координат|координатами]]»: ''именем'' и ''номером ревизии''. Для однозначной адресации объекта необходимо указание обоих параметров. При необходимости указания на конкретную ревизию объекта используется запись вида: <tt>имя@ревизия</tt>, например, <tt>/main.c@29</tt> — файл /main.c в ревизии 29. Такое указание ревизии, используемое для уточнения имени, называется ''стержневая ревизия'' ({{lang-en|peg revision}}).

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

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

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

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

Номер ревизии является аналогом [[Время|времени]] в том смысле, что меньшие номера ревизий соответствуют более ранним состояниям хранилища, а бо́льшие — поздним:
* Минимальный номер ревизии 0 (ноль) соответствует изначальному состоянию хранилища, когда еще не было опубликовано ни одной правки. В нулевой ревизии хранилище содержит только пустую корневую директорию.
* Максимальный номер ревизии соответствует самому последнему состоянию хранилища, то есть состоянию после публикации последней правки. Вместо указания номера последней ревизии можно использовать ключевое слово <tt>HEAD</tt> (головная ревизия); это удобно, поскольку номер головной ревизии увеличивается при каждой публикации изменений.

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

===== Оперативная и cтержневая ревизии =====
[[Изображение:561px-Subversion peg revision RU.svg.png|400px|thumb|'''Рисунок 2'''. Указание стержневой ревизии]]

Номер ревизии используется в двух различных [[Контекст|контекстах]]:
* '''Оперативная''' ревизия ({{lang-en|operative revision}})
* '''Стержневая''' ревизия ({{lang-en|peg revision}})
Ревизия называется оперативной, если она указывается как ревизия или диапазон ревизий, к которому должна быть применена команда, например:

 svn log -r 199:230 <nowiki>http://...</nowiki>

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

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

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

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

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

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

Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции<ref>Здесь перечислены операции именно с точки зрения ''файловой системы хранилища''. В рабочей копии действия над объектами несколько иные. Однако изменения в рабочей копии, будучи опубликованными, вызовут в хранилище описанные здесь действия. Например, команда <tt>svn move</tt> в рабочей копии произведёт операции <tt>D</tt>, <tt>A+</tt> в хранилище.</ref> (смотри также '''рисунок 1'''). В скобках указано краткое именование операции в обозначениях команды <tt>svn status</tt>.

* '''''Добавление''''' ('''A'''). Добавление объекта в файловую систему. Добавленный объект не имеет истории ревизий. Пример на рисунке:
:* файл <tt>/main.c</tt> был ''добавлен'' в ревизии 27.

* '''''Модификация''''' ('''M'''). Модификация объекта, например, изменение содержимого файла или изменение свойств файла или директории. Пример на рисунке:
:* файл <tt>/main.c</tt> был ''модифицирован'' в ревизии 28.

* '''''Удаление''''' ('''D'''). Удаление файла с головной и последующих ревизий. При этом файл остаётся в предыдущих ревизиях. Пример на рисунке:
:* файл <tt>/main.c</tt> был ''удалён'' в ревизии 30.

* '''''Добавление с историей''''' ('''A+'''). Представляет собой копирование объекта внутри файловой системы хранилища, то есть объект <tt>имя_источника@ревизия_источника</tt> копируется в <tt>имя_копии@HEAD</tt>. Скопированный объект наследует от источника историю ревизий до момента копирования (наследование истории показано на рисунке пунктирными связями). Примеры на рисунке:
:* в ревизии 29 директория <tt>/tags/R1</tt> была скопирована с директории <tt>/trunk@27</tt>.
:* в ревизии 31 файл <tt>/main.c</tt> был скопирован с <tt>/main.c@29</tt>, то есть с более ранней ревизии самого себя. Таким образом, произведено восстановление ранее удалённого (в ревизии 30) файла с сохранением истории ревизий.

* '''''Замена''''' ('''R+'''). Имеет место в случае, когда в одной ревизии произведено и удаление объекта ('''D'''), и добавление с историей ('''A+''') объекта с тем же самым именем. Хотя имя при операции замены остается неизменным, Subversion рассматривает объект ''до'' и ''после'' замены как два различных объекта с различными историями ревизий (история старого заканчивается в точке замены, история нового наследуется от источника копирования и продолжается далее). Пример на рисунке:
:* в ревизии 30 файл <tt>/file.txt</tt> был ''заменен'': старый файл <tt>/file.txt</tt> удален, а новый файл с тем же именем скопирован с файла <tt>/bar.txt@29</tt>.

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

Рабочая копия является самодостаточной в том смысле, что Subversion не хранит каких-либо данных, относящихся к рабочей копии, вне её. Поэтому, имея одну рабочую копию, можно простым копированием получить несколько без затрат сетевого трафика. В служебных директориях рабочей копии, помимо прочего, хранится (в директориях <tt>.svn/text-base/</tt>) так называемая ''чистая копия'' ({{lang-en|pristine copy}}) — файлы рабочей копии в неизменённом виде, как они были извлечены из хранилища. Наличие чистой копии позволяет быстро и без обращения к хранилищу выполнять операции просмотра и отката локальных изменений. Однако размер рабочей копии на диске примерно в два раза больше (данные + чистая копия данных), чем размер самих данных. Такой подход обусловлен тем, что дисковые ресурсы дешевле и доступнее, чем ресурсы сети передачи данных.

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

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

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

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

=== Структура хранилища ===

==== Структура проекта в хранилище ====
Subversion не накладывает каких-либо ограничений на структуру директорий в файловой системе хранилища, она может быть какой угодно в рамках правил именования объектов файловой системы. Тем не менее, существуют некоторые общепринятые «правила хорошего тона». В простейшем случае в корневой директории файловой системы имеются как минимум три директории:
 /branches
 /tags
 /trunk
Директория <tt>/trunk</tt> содержит основную линию разработки проекта, <tt>/branches</tt> содержит все [[Ветвь (управление версиями)|ветви]], <tt>/tags</tt> содержит все метки. Такая структура удобна для хранилища, содержащего только один проект. Если проектов несколько, то более удобна следующая структура:
  /project1
    /branches
    /tags
    /trunk
  /project2
    /branches
    /tags
    /trunk
то есть в корневой директории находятся директории проектов, и в каждом из них есть свои <tt>/trunk</tt>, <tt>/branches</tt>, <tt>/tags</tt>, относящиеся только к этому проекту. Описанные структуры директорий хранилища являются лишь примерами, на практике хранилище можно организовать таким способом, который оптимально подходит в данном конкретном случае<ref>[http://rsdn.ru/article/devtools/subversions.xml#EDC Структура проектов на C++ с использованием Subversion и Mxx_ru]</ref><ref>[http://rsdn.ru/article/devtools/VrezkaSVN.xml Хранение сложных проектов в репозитории и установка tag’ов на несколько проектов сразу]</ref>.

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

==== [[Ветвь (управление версиями)|Ветви]] ====

Subversion использует «файловую» модель (такую же, как и в [[Perforce]]<ref>[http://www.perforce.com/perforce/branch.html Inter-File Branching in Perforce]</ref>) для реализации ветвей и меток. Новая ветвь или метка создаётся командой <tt>svn copy</tt>, которая создаёт в хранилище копию источника с сохранением истории ревизий ([[#Операции над файловой системой|A+]]). Полученная копия будет ветвью (или меткой, в зависимости от способа работы с ней). В дальнейшем изменения, сделанные на ветви, могут быть перенесены на источник, от которого была создана эта ветвь, такое распространение изменений называется ''слияние'' ({{lang-en|merge}})

Операции копирования в Subversion ''дешёвые'' ({{lang-en|cheap copy}}), то есть требуют небольшого фиксированного количества времени и дискового пространства. Хранилище спроектировано таким образом<ref>[http://subversion.tigris.org/design.html#server.fs.struct.bubble-up Bubble-Up Method]</ref>, что при любом копировании происходит не дублирование данных, а создание ссылки на источник (аналогично [[Жёсткая ссылка|жёсткой ссылке]]), однако этот механизм чисто внутренний — с точки зрения пользователя происходит именно создание копии.
[[Image:800px-Subversion project visualization.svg.png|650px|thumb|center|'''Рисунок 3'''. Пример эволюции ветвей в Subversion]]

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

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

* '''''Релизная ветвь''''' ({{lang-en|release branch}}). Во время выпуска [[Релиз (программное обеспечение)|релиза]] программного обеспечения недопустимо публиковать потенциально дестабилизирующие изменения исходного кода, поэтому перед выпуском релиза обычно создается ''релизная ветвь'', в которую публикуются только исправления ошибок. Все остальные изменения публикуются в стволовую ветвь. Таким образом, стабильность кода на релизной ветви не нарушается и релиз выпускается из кода этой ветви. В дальнейшем можно путем слияния перенести исправления, сделанные на релизной ветви, и на стволовую ветвь.
* '''''Функциональная ветвь''''' ({{lang-en|functional branch}}).


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

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

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

: '''Недостатки''':
:* Для объекта файловой системы очень трудно узнать, в какие метки он вошёл.
:* Если права доступа установлены индивидуально<ref>[http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html Path-Based Authorization]</ref> для директорий, то метка эти права не наследует.
:* Помеченные данные могут быть изменены.
:* Публикация изменений в рабочей копии, созданной из метки, изменит саму метку, а не те данные, которые были помечены. Вместо этого нужно создавать рабочую копию из того, что является источником этой метки.

=== Свойства (properties) ===

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

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

===== Свойства файлов =====
; <tt>svn:executable</tt> : Делает файл исполняемым (для рабочих копий под операционными системами семейства [[UNIX]]).
; <tt>svn:mime-type</tt> : Хранит [[MIME]]-тип файла. Влияет на способ работы команд, показывающих разницу файлов, а также объединяющих изменения (merging).
; <tt>svn:keywords</tt> : Список ''ключевых слов'' ({{lang-en|keywords}}), которые будут заменены в файле соответствующими значениями. Чтобы замена произошла, ключевое слово должно присутствовать в файле в виде <tt>$keyword$</tt>. Используется для того, чтобы автоматически обновлять в файле значения, меняющиеся от версии к версии (например, номер ревизии).
; <tt>svn:eol-style</tt> : Определяет правило преобразования [[символ конца строки|символов конца строки]] ({{lang-en|end-of-line}}, EOL) в текстовом файле. Используется в случаях, когда файл должен иметь конкретный тип символов EOL. Обычно используется «native» — при этом тип символов конца строки соответствует принятому в той операционной системе, в которой происходит создание рабочей копии.
; <tt>svn:needs-lock</tt> : Означает, что при извлечении из хранилища файл будет доступен только для чтения. Это свойство предназначено для использования совместно с механизмом ''блокировки''. Запрет записи в файл является напоминанием того, что надо получить блокировку на этот файл, прежде чем его редактировать: при получении блокировки клиентская программа Subversion автоматически делает файл доступным для записи (снятие блокировки снова делает файл защищенным от модификаций). Блокировки могут быть использованы и без установки этого свойства. Однако делать это не рекомендуется, так как существует риск того, что другой пользователь может начать редактировать заблокированный файл, и это обнаружится только при публикации изменений.
; <tt>svn:special</tt> : Свойство не предназначено для установки или модификации пользователями. В настоящее время используется для хранения [[Символьная ссылка|символьных ссылок]] в репозитории. Когда символьная ссылка добавляется в репозиторий, в репозитории создаётся файл с установленным свойством <tt>svn:special</tt>. Когда этот файл извлекается в [[UNIX]]-подобной системе, клиентская программа Subversion преобразует его обратно в ссылку.

===== Свойства директорий =====
; <tt>svn:ignore</tt> : Список шаблонов имён файлов и директорий, которые клиентская программа Subversion будет игнорировать в данной директории. Это свойство аналогично файлу <tt>.cvsignore</tt> в [[CVS]]. Как правило, свойство настраивается таким образом, чтобы клиентская программа «не видела» файлы и директории, которые автоматически создаются различными программами и не должны быть версионированы (например, [[Объектный файл|объектные файлы]], [[Временный файл|временные файлы]] и т. п.). Действие этого свойства не распространяется на поддиректории.
; <tt>svn:externals</tt> : Позволяет автоматически извлечь в рабочую копию набор директорий, указав их [[URL]] (можно даже из другого хранилища).

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

; <tt>svn:date</tt> : Дата и время создания ревизии.
; <tt>svn:author</tt> : Имя пользователя, который опубликовал изменения, вошедшие в эту ревизию.
; <tt>svn:log</tt> : Описание изменений, опубликованных в этой ревизии (текст, введенный пользователем при публикации изменений).

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

== Subversion и CVS ==

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

{| border=1 class="TablePager"
 !Параметр
 !Subversion
 !CVS
 |-
 !colspan=3 |Возможности
 |-
 !Директории
 |Отслеживает версии не только файлов, но и директорий.
 |Версии директорий не отслеживаются, то есть структура директорий одна и та же (та, которая существует в хранилище на данный момент) для всех ревизий и всех веток. При извлечении старых состояний получаем правильные (старые) ревизии файлов, но в неправильной (существующей на момент извлечения) структуре директорий.
 |-
 !Транзакции
 |Атомарность многофайловых публикаций.
 |Атомарность только на уровне однофайловых публикаций. Фактически публикация изменений в нескольких файлах разбивается на последовательность публикаций изменений отдельных файлов. Если такая публикация прервана, то часть файлов остается опубликованной, часть - не опубликованной.
 |-
 !Наборы изменений
 |Наборы изменений ({{lang-en|changeset}}) поддерживаются.
 |Наборы изменений не поддерживаются.
 |-
 !Модификации имён файлов
 |Поддерживает копирование, перемещение и переименование файлов и директорий с сохранением истории изменений.
 |При копировании, перемещении и переименовании файлов файл с новым именем не имеет никакой истории, то есть связь со старым именем и его историей версий полностью теряется. То же самое для файлов внутри директории при модификации её имени<ref>Директорию можно переместить прямо в хранилище средствами [[Файловая система|файловой системы]], при этом файлы в нём не потеряют историю. Однако эта модификация подействует на все ревизии и ветви файлов в этой директории (поскольку директории не имеют версионной информации в CVS)</ref>.
 |-
 !Свойства (properties)
 |С каждым файлом и директорией может быть связан произвольный набор свойств, состоящих из названия и значения. Свойства тоже находятся под управлением версиями.
 |Свойства не поддерживаются
 |-
 !Блокировки
 |Поддерживается необязательная блокировка файлов (начиная с версии 1.2).
 |Блокировки не поддерживаются, но есть похожий механизм, называемый ''слежение''
 |-
 !Ветви
 |Ветви (''branch'', см. [[Система управления версиями#Словарь|словарь]]) реализованы в пространстве путей. Это значит, что для создания ветви производится копирование директории (копия и будет ветвью). Создание таких копий — быстрая и не ресурсоёмкая операция, потому что данные не дублируются, вместо этого публикуется новая версия, отличающаяся от предыдущей лишь расположением файлов.
 |Ветви реализованы в «третьем измерении». Это значит, что файл на ветви адресуется тремя параметрами: ''путём'' в файловой системе, ''ревизией'' (или другим способом указания ревизии, например, временем), ''именем ветви''.
 |-
 !Метки
 |Нет меток (''tag'', см. [[Система управления версиями#Словарь|словарь]]), как таковых. Вместо них используется иерархия директорий&nbsp;— для метки создаётся отдельная директория (как и для ветви). Метка — это ветвь, в которой по договоренности больше не делают изменений.
 |Метки поддерживаются
 |-
 !colspan=3 |Эффективность
 |-
 !Клиент-серверный обмен
 |При любых обновлениях версий между клиентом и сервером передаются только различия между файлами, что может существенно уменьшить сетевой трафик.
 |С сервера к клиенту передаются различия, с клиента на сервер объект передаётся полностью
 |-
 !Двоичные файлы
 |Одинаково эффективно работает как с [[Текстовый файл|текстовыми]], так и с [[Двоичный файл|двоичными файлами]].
 |Работа с двоичными файлами менее эффективна: каждая новая версия сохраняется в хранилище полностью.
 |-
 !Создание ветвей и меток
 |Требуется небольшое фиксированное количество времени и дискового пространства.
 |Затраты времени велики (зависят от количества задействованных файлов). Имена ветвей и меток хранятся избыточно (во всех задействованных файлах).
 |-
 !Накладные расходы в рабочей копии
 |В служебных директориях рабочей копии хранится чистая копия. Поэтому операции просмотра и отката локальных изменений выполняются быстро (без обращения к хранилищу), однако размер рабочей копии на диске примерно в два раза больше, чем размер самих данных.
 |Чистая копия не хранится, размер рабочей копии примерно равен размеру данных. В результате операции просмотра и отката локальных изменений требуют доступа к хранилищу и выполняются медленно.
 |-
 !Расход [[ОЗУ|памяти]] на стороне сервера
 |Меньше<ref>http://subversion.tigris.org/faq.html#server-requirements</ref>
 |Больше.
 |}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

; Fs : Самый низкий уровень; реализует версионированную файловую систему, которая и хранит данные.
; Repos : Уровень хранилища, реализованного на файловой системе. На этом уровне реализовано множество вспомогательных функций, а также поддерживается запуск обработчиков ({{lang-en|hooks}}), то есть скриптов, которые запускаются при наступлении некоторого события. Вместе уровни Fs и Repos составляют ''интерфейс файловой системы''.
; mod_dav_svn : Обеспечивает [[WebDAV]]/[[Delta-V]]-доступ через Apache 2.
; Ra : Реализует доступ к хранилищу (и локальный, и удалённый). Начиная с этого слоя на хранилище можно ссылаться по URL, то есть
;* <tt>file:///path/</tt> для локального доступа,
;* <tt><nowiki>http://host/path/</nowiki></tt> или <tt><nowiki>https://host/path/</nowiki></tt> для доступа через WebDAV , или
;* <tt>svn://host/path/</tt> или <tt>svn+ssh://host/path/</tt> для доступа через протокол SVN.
; Client, Wc : Самый высокий уровень. Абстрагирует доступ к хранилищу и обеспечивает выполнение типичных задач клиента, таких, как аутентификация пользователя или сравнение версий. Client использует библиотеку Wc для управления локальной рабочей копией.

== Недостатки ==
Subversion не всегда может правильно обработать операции переименования файлов, если одновременно с переименованием изменяется и содержимое файла. Проблемы могут также возникнуть, если файл, переименованный в локальной копии, кто-то другой изменил в хранилище. Часть этих проблем исправлена в версии 1.5, однако это решение пока не полное.<ref>[http://subversion.tigris.org/svn_1.5_releasenotes.html#copy-move-improvements Copy/move-related improvements in Subversion 1.5]</ref>

Также слабым местом Subversion считают операции слияния веток. До версии 1.5 все такие операции пользователям приходилось отслеживать вручную, с помощью подробных записей в журнале изменений. В текущей версии появилась базовая поддержка автоматического отслеживания слияний, которую разработчики планируют улучшить в последующих релизах.<ref>[http://subversion.tigris.org/svn_1.5_releasenotes.html#merge-tracking Merge tracking (foundational)]</ref>

Информация, однажды помещённая в хранилище Subversion, остаётся там навсегда: файл можно удалить в текущей ревизии, но всегда есть возможность получить из хранилища одну из предыдущих ревизий, в которых файл существовал. Хотя сохранность прошлых ревизий и является, собственно, целью использования систем управления версиями, иногда бывает необходимо полностью удалить из хранилища информацию, попавшую туда по ошибке. В Subversion не предусмотрено для этого никакого штатного способа<ref>[http://subversion.tigris.org/issues/show_bug.cgi?id=516 svn obliterate]</ref>; единственная возможность заключается в создании [[дамп]]а хранилища, его редактировании (это текстовый файл) и последующем восстановлении хранилища из дампа. Существуют сторонние программы для автоматизации этого процесса, но, в любом случае, для выполнения этой операции требуется временное прекращение доступа к хранилищу и вмешательство администратора с привилегиями, достаточно высокими для того, чтобы полностью стереть старое хранилище и заменить его новым.

== Примечания ==
{{примечания}}

== См. также ==
* [[TortoiseSVN]]
* [[USVN]]
* [[AnkhSVN]]

== Ссылки ==
* [http://subversion.tigris.org/ Официальный сайт] {{ref-en}}
* Книга [http://svnbook.red-bean.com/ «Управление версиями в Subversion»], Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато
* [http://subversion.tigris.org/links.html Ссылки на официальном сайте] {{ref-en}}
* [http://www.collab.net/community/subversion/articles/ Статьи] на [http://www.collab.net/community/subversion/ CollabNet Subversion Community] {{ref-en}}
* [http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html Merging and branching in Subversion 1.5] {{ref-en}} By John Ferguson Smart, JavaWorld.com.
* [http://blog.red-bean.com/sussman/?p=79 Version Control and «the 80 %»] {{ref-en}} Бен Коллинз-Сассман (создатель Subversion) о будущем Subversion и о распределённых системах. [http://lib.custis.ru/index.php/Version_Control_and_%E2%80%9Cthe_80%25%E2%80%9D Русский перевод этой статьи].

=== Публичные хранилища SVN ===
* [http://sourceforge.net http://sourceforge.net] — [[SourceForge.net]], наиболее популярный хостинг [[свободное ПО|свободных проектов]].
* [http://svn.berlios.de/wsvn http://svn.berlios.de/wsvn] — [[BerliOS]]
* [http://code.google.com/projects.html Google Code]
* [http://assembla.com http://assembla.com]
* [http://subversion.tigris.org/links.html#hosting Cписок на официальном сайте Subversion]

{{Википедия}}

[[Категория:Прикладное программное обеспечение]]

[[en:Subversion (software)]]