Эта статья входит в число хороших статей

Subversion

Материал из Википедии — свободной энциклопедии
(перенаправлено с «SVN»)
Стабильная версия, проверенная 4 мая 2024.
Перейти к навигацииПерейти к поиску
В этой статье может бытьслишком многоссылок на другие статьи, и, возможно, их количествонужно сократить.
Пожалуйста, оформите её согласноправилам расстановки и оформления внутренних ссылок и удалите повторяющиеся ссылки и все ссылки, не относящиеся к контексту.(15 апреля 2023)
У этого термина существуют и другие значения, см.Subversion (игра).
Subversion
Логотип программы Subversion
Типцентрализованная система управления версиями[вд], проект Фонда Apache[вд] и открытое программное обеспечение
АвторCollabNet[вд]
РазработчикApache Software Foundation
Написана наСи[3][4], Python[3], C++[3], Java[3], Ruby[3] и Perl[3]
Операционные системыGNU/Linux[5], Windows[5], macOS[5] и BSD[вд][5]
Первый выпуск20 октября2000[1]
Последняя версия1.14.3 (28 декабря 2023; 14 месяцев назад (2023-12-28))
Тестовая версия
Репозиторийsvn.apache.org/repos/asf…
Читаемые форматы файлов:
SVN dump format (v1)[вд], SVN dump format (v2)[вд], SVN dump format (v3)[вд] и SVN dump format (generic)[вд]
Создаваемые форматы файлов:
SVN dump format (v1)[вд], SVN dump format (v2)[вд], SVN dump format (v3)[вд] и SVN dump format (generic)[вд]
ЛицензияApache License 2.0[6]
Сайтsubversion.apache.org (англ.)
Логотип Викисклада Медиафайлы на Викискладе

Subversion[7] (также известная как «SVN»[8]) —свободная централизованнаясистема управления версиями, официально выпущенная в2004 году компаниейCollabNet[англ.]. С 2010 года Subversion является одним из проектовApache Software Foundation и официально называетсяApache Subversion (зарегистрированныйтоварный знак[9]).

Цель проекта в начале разработки — заменить[10][11] распространённую на тот момент системуConcurrent Versions System (CVS), которая на сегодняшний день считается морально устаревшей[12][13][14]. Subversion обладает всеми основными функциями CVS и избавлена от ряда недостатков последней.

Subversion всё ещё используется некоторыми сообществами разработчиковоткрытого программного обеспечения (в том числе сообществами, ранее использовавшимиCVS), но почти все крупные проекты перешли наDVCS. В числе последних пользователей Subversion среди открытых проектов остаётсяFreeBSD, но и они анонсировали переход наGit[15]. Довольно долго использовали Subversion такие известные проекты, какApache,GCC,FFmpeg,LLVM,Free Pascal. Subversion также используется в закрытых проектах и корпоративной сфере, но насколько широко — оценить непросто.Хостинг Subversion, в том числе для проектов с открытым кодом, также предоставляют популярные хостинг-проектыSourceForge.net,Tigris.org,Google Code иBountySource.

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

По данным статистики использования пакетовLinux-дистрибутивовDebian[17] иUbuntu[18], количество активных пользователей Subversion достигло максимума примерно в 2010 году, и начало снижаться с 2016 года. Тем не менее, количество проектов, использующих Subversion всё ещё больше, чем использующихCVS,Mercurial иBazaar (по состоянию на август2019 года).

В качестве официальной документации позиционируется[19] книга издательстваO’Reilly Media, выложенная в свободный доступ[20] и дописываемая авторами по мере выхода новых версий SVN. Там же публикуются её переводы на ряд языков, в том числе русский, но при том, что англоязычные версии книги сейчас описывают версии 1.8 и 1.7, на русском языке имеются лишь книги, описывающие версии до 1.4 включительно[21].

Содержание

История

[править |править код]

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

Основные события истории развития Subversion.

  • 31 августа2001 года команда разработчиков перешла с CVS на Subversion для управления собственным исходным кодом: Subversion стала «самодостаточной».
  • 23 февраля2004 года вышла версия 1.0.0[23]. К этому времени Subversion уже использовалась примерно на 1400 серверах с открытым доступом.[24]
  • 29 сентября2004 года появился релиз 1.1.0. Среди основных нововведений — новый формат хранилища на основе обычных файлов (FSFS), в дополнение к существовавшему ранее (с использованиемBerkeley DB).[25]
  • 21 мая2005 года вышел релиз 1.2.0, в котором добавлена возможность блокировки файлов,[26] что позволило улучшить поддержку клиентов WebDAV/DeltaV, в том числе, реализовать автоматическое создание новых версий при редактировании файлов с помощью таких клиентов. Начиная с этого релиза Subversion по умолчанию использует FSFS для новых хранилищ.
  • 30 декабря2005 года вышел релиз 1.3.0.[27] Основными изменениями являются возможность устанавливать права доступа к каталогам при использовании svnserve, дополнительные возможности команд, а также множество улучшений для разработчиков.
  • 10 сентября2006 года вышел релиз 1.4.0.[28] Он поддерживает работу с BerkeleyDB 4.4 и может использовать её функции самовосстановления. Ранее при сбоях Subversion хранилище, использующее BerkeleyDB, могло остаться в «заклиненном» состоянии и требовалось вмешательство администратора для восстановления работы системы (при использовании FSFS этой проблемы нет).
  • 19 июня2008 года вышел релиз 1.5.0[29], в нём сделано множество улучшений, самым значительным из которых является базовая поддержка отслеживания слияний (англ. merge tracking). Эта возможность делает процесс слияния пакетов в Subversion более простым и надёжным.
  • 20 марта2009 года вышел релиз 1.6.0.[30] Улучшения поддержкиsvn:externals, обнаружение «конфликтов деревьев» (англ. tree conflict), улучшение эффективности хранения данных в репозитории и другие внесённые изменения.
  • В феврале2010 года проект Subversion был официально переведён под управлениеApache Software Foundation (ASF)[31]. Президент Subversion Corporation и директорOpen Source в WANdisco выступил с видеообращением, в котором с энтузиазмом пообещал всем, что переход Subversion к ASF будет лишь способствовать более активному развитию проекта.[32]
  • 11 октября2011 года состоялся релиз 1.7[33]. Основные улучшения: теперь только одна папка.svn в корне рабочей копии; ускорена работа по HTTP; добавлена утилитаsvnrdump; новая командаsvn patch.
  • 18 июня2013 года вышел релиз 1.8.0.[34] Apache Subversion 1.8 является расширением всех предыдущих выпусков Subversion.

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

[править |править код]

Возможности

[править |править код]
  • Хранение полнойистории изменений отслеживаемых объектов (файлов,каталогов,символьных ссылок[35]) в централизованномхранилище (репозитории), в том числе при изменении атрибутов («метаданных»), перемещении, переименовании и удалении
  • Копирование объектов с разветвлением истории — при копировании в хранилище появляются два отдельных объекта с общей историей
  • Поддержкапереноса изменений между копиями объектов, в том числе полногослияния копий (в рабочей копии; без объединения истории)
  • Эмуляция[36]ветвления:
    • создание ветвей с помощью копирования каталогов и последующая независимая работа с ними
    • слияние ветвей с автоматическим определением и переносом изменений
  • Эмуляция[36]меток (копированием каталогов)
  • История изменений и копии объектов (в том числе ветви и метки) хранятся в виде связанных разностных копий — «дешёвых» (не требующих больших временны́х и дисковых ресурсов) при создании и хранении
  • Поддержка конкурентной (в том числе одновременной, с изоляцией транзакций) многопользовательской работы с хранилищем и, в большинстве случаев, автоматическим слиянием изменений различных разработчиков (в рабочей копии)
  • Фиксации изменений в хранилище (в том числе многообъектные) организуются в видеатомарных транзакций
  • Сетевой обмен между сервером и клиентом предусматривает передачу только различий между рабочей копией и хранилищем
  • Обеспечивается одинаково эффективная работа как стекстовыми, так и сдвоичными файлами
  • Различные варианты доступа к хранилищу, в том числе:
    • непосредственный доступ на локальной файловой системе;
    • по собственному сетевому протоколу;
    • черезвеб-сервер по протоколуWebDAV/DeltaV.
  • Вывод клиента командной строки одинаково удобен и для чтения, и для разбора программами
  • Возможность зеркалирования хранилища
  • Два возможных внутренних формата хранилища (англ. repository): база данных или набор обычных файлов
  • Интернационализированные сообщения программы (используются настройкилокали)
  • Библиотеки для языковPHP,Python,Perl,Java позволяют встроить функциональность клиента Subversion в программы, написанные на этих языках
  • Многоуровневая архитектурабиблиотек, изначально рассчитанная наклиент-серверную модель

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

[править |править код]

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

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

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

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

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

[править |править код]

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

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

Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS. При выпуске релиза 1.8 использование Berkeley DB было объявлено нерекомендованным[34]. Новые возможности, которые будут добавлены в следующих релизах, могут не работать на серверах, использующих Berkeley DB. В дальнейшем поддержка Berkeley DB может быть прекращена.

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

[править |править код]

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

  • прямой доступ к репозиторию на диске (на локальной или сетевой файловой системе);
  • удалённый доступ по протоколуWebDAV/DeltaV поверхHTTP (илиHTTPS) с использованием модуляmod_dav_svn для веб-сервераApache 2;
  • удалённый доступ с использованием собственного протоколаSVN:
    • на выделенном сетевом соединении (по умолчанию на TCP-порту 3690);
    • через стандартный ввод-вывод (в том числе через средства удалённогоCLI, например,SSH).

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

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

[править |править код]

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

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

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

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

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

Имена файлов

[править |править код]

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

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

[править |править код]

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

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

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

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

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

Оперативная и стержневая ревизии
[править |править код]
Рис. 2. Указание стержневой ревизии

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

  • оперативной ревизии (англ. operative revision);
  • стержневой ревизии (англ. peg revision).

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

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

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

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

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

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

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

В качестве стержневой ревизии следует указывать как можно более позднее состояние интересующего объекта. Причина этого в том, что цепочка состояний однозначно отслеживается «назад», но не «вперёд». Например, URL со стержневой ревизиейhttp://some.path/foo.txt@31 принадлежит двум цепочкам состояний (выделены соответственно зелёным и серым фоном). Из этих двух цепочек указанный URL адресует серую цепочку, то есть при движении «вперёд» от стержневой ревизии операции копирования игнорируются.

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

[править |править код]

Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции[39] (см. рис. 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 1.6 и более ранних версий также является полноценной рабочей копией, поскольку в каждом каталоге хранятся его служебные данные (каталоги.svn). Начиная с версии 1.7 в каждой рабочей копии присутствует только один каталог.svn в корне её каталога.

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

В служебных каталогах рабочей копии, помимо прочего, хранится так называемаячистая копия (англ. pristine copy) — файлы рабочей копии в неизменённом виде, как они были извлечены из хранилища (для svn это ревизия с именем BASE). Наличие чистой копии позволяет быстро и без обращения к хранилищу выполнять операции просмотра и отката локальных изменений. Однако размер рабочей копии на диске примерно в два раза больше (данные + чистая копия данных), чем размер самих данных. Такой подход обусловлен тем, что дисковые ресурсы дешевле и доступнее, чем ресурсысети передачи данных.

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

Транзакции

[править |править код]

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

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

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

Локальные и удалённые формы команд

[править |править код]

Все команды клиента Subversion можно разделить на следующие группы:

  • модифицирующие рабочую копию;
  • модифицирующие хранилище;
  • модифицирующие и рабочую копию, и хранилище;
  • не модифицирующие ничего.

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

[править |править код]

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

[править |править код]

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

/.branchestagstrunk

Вся файловая структура проекта (основной линии разработки) должна содержаться в подкаталогеtrunk, подкаталогbranches должен содержатьветви проекта, аtags —метки. Например, следующая структура каталогов хранилища:

/.branches    branch_1tags    tag_1    tag_2trunk

предполагает наличие у проекта (trunk) одной ветви «branch_1» и двух меток «tag_1» и «tag_2». Каждый из этих каталогов (trunk,branch_1,tag_1 иtag_2) содержит копию соответствующей версии проекта.

Если (под)проектов в хранилище несколько, то такая структура подкаталогов создаётся для каждого (под)проекта:

/.project1    branches    tags    trunkproject2    branches    tags    trunk

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

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

Ветви

[править |править код]
Основная статья:Ветвь (управление версиями)

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

Метки

[править |править код]

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

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

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

  • метка видна в структуре каталогов, можно сделать удобную древовидную организацию меток.

Недостатки:

  • трудно узнать, в какие метки вошёл файл (то же для каталога);
  • если права доступа установлены индивидуально[43] для каталогов, то метка эти права не наследует;
  • содержимое метки может быть изменено;
  • если из метки создать рабочую копию и зафиксировать из этой рабочей копии какие-либо изменения, то это изменит саму метку, а не те данные, которые были помечены. Правильным способом работы «от метки» является создание рабочей копии не из метки, аиз того, что является источником этой метки.

Свойства (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:mergeinfo
Хранит информацию о том, из каких путей было произведенослияние в этот файл. Свойство введено в версии 1.5, оно используется дляотслеживания слияний (англ. merge tracking). Представляет собой набор строк видаимя_файла: диапазон_ревизий. Здесьимя_файла — полное (с путём от корня файловой системы репозитория) имя файла или каталога, откуда было произведено слияние указанного диапазона ревизий. Строки модифицируются автоматически при операциях слияния; при последующих слияниях Subversion учитывает ранее вписанные строки, избегая тем самым повторных слияний одних и тех же изменений. Не рекомендуется изменять свойствоsvn:mergeinfo вручную — это может нарушить механизм отслеживания слияний.
Свойства каталогов
[править |править код]
svn:ignore
Список шаблонов имён файлов и каталогов, которые клиентская программа Subversion будет игнорировать в данном каталоге. Это свойство аналогично файлу.cvsignore вCVS. Как правило, свойство настраивается таким образом, чтобы клиентская программа «не видела» файлы и каталоги, которые автоматически создаются различными программами и не должны быть версионированы (например,объектные файлы,временные файлы и т. п.). Действие этого свойства не распространяется на подкаталоги.
svn:externals
Позволяет автоматически извлечь в рабочую копию набор каталогов, указав ихURL (можно даже из другого хранилища).
svn:mergeinfo
То же, что идля файлов.

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

[править |править код]

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

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

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

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

[править |править код]

Рабочий цикл

[править |править код]

Типичная итерация рабочего цикла с Subversion включает следующие этапы.

  • Обновлениерабочей копии из хранилища (svn update) или её создание (svn checkout).
  • Изменение рабочей копии. Изменения каталогов и информации о файлах производится средствами Subversion, визменении же (содержимого) файлов Subversion никак не задействован — изменения производятся программами, предназначенными для этого (текстовые редакторы,средства разработки и т. п.):
    • новые (ещё не зафиксированные в хранилище) файлы и каталоги нужнодобавить (командаsvn add), то есть передать под управление версиями;
    • если файл или каталог в рабочей копии нужноудалить,переименовать,переместить илископировать, необходимо использовать средства Subversion (svn mkdir,svn delete,svn move,svn copy);
    • просмотр состояния рабочей копии и локальных (ещё не зафиксированных) изменений (svn info,svn status,svn diff);
    • любые локальные изменения, если они признаны неудачными, можнооткатить (svn revert).
  • При необходимости — дополнительное обновление, для получения изменений, зафиксированных в хранилище другими пользователями и слияния этих изменений со своими (svn update).
  • Фиксация своих изменений (и/или результатов слияния) в хранилище (svn commit).

Ветвление

[править |править код]

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

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

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

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

[править |править код]

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

svn copy http://.../trunk/dir http://.../branches/branch_name -m "Creating a branch of dir"

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

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

Работа с ветвями

[править |править код]

В целом работа на ветви не отличается от работы на основной линии разработки (trunk). Специфичные команды требуются только для действий, в которых задействовано более одной ветви. К таким командам относятся (помимо команды создания ветвиsvn copy):

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

Как правило, полный цикл работы с ветвями включает следующие этапы:

  • создание ветви (svn copy);
  • переключение имеющейся рабочей копии на ветвь (svn switch) или создание новой рабочей копии путём закачки (svn checkout);
  • изменение файлов и каталогов в рабочей копии, фиксация этих изменений (svn commit);
  • копирование в ветвь свежих изменений из родительской ветви, сделанных после ветвления (svn merge,svn commit);
  • копирование изменений из ветви в родительскую ветвь (svn merge,svn commit);
  • удаление ветви (svn delete), если её жизненный цикл закончен.

Слияние

[править |править код]

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

[править |править код]

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

Терминология, связанная со слиянием, несколько запутана. Терминслияние (англ. merge) является не совсем точным, поскольку как такового объединения ветвей не происходит. Кроме того, не следует отождествлятьслияние и командуsvn merge: во-первых, для слияния нужно выполнить (помимоsvn merge) разрешение конфликтов и фиксацию, во-вторых, применениеsvn merge не ограничивается слиянием.

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

[править |править код]

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

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

Создание хранилища

[править |править код]

Для создания хранилища используется командаsvnadmin create. Эта операция создаст пустое хранилище в указанном каталоге.

Subversion и CVS

[править |править код]

Сравнение

[править |править код]

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

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

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

[править |править код]

Уровни

[править |править код]

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 — SVN, конфигурируется переменными окружения иINI-файлами, создаваемыми в домашнем каталоге пользователя в подкаталоге.subversion (расположение конфигурации в Windows-системах, в файлах или реестре, зависит от системных настроек). В конфигурации SVN также кеширует SSL-сертификаты, логины, пароли и т. п. (если это не запрещено в конфигурации) для доступа к серверам Subversion.

Содержимое каталога.subversion:

  • файлservers — содержит информацию о способах сетевого подключения к удалённому репозиторию;
  • файлconfig — содержит прочую конфигурационную информацию[48]
  • каталогauth — содержиткеш серверов, сертификатов, логинов и паролей
  • файлREADME.txt — документация по конфигурированию SVN

Недостатки

[править |править код]

Проблемы при переименовании файлов

[править |править код]

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

Слабая поддержка слияния ветвей

[править |править код]

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

Невозможность удаления данных из хранилища

[править |править код]

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

Дополнительное программное обеспечение

[править |править код]
  • Клиенты:
  • Плагины:
  • Веб-интерфейсы:
    • Trac — инструмент, основанный на технологии Wiki,
    • Redmine — дополнительно отслеживает ошибки,
    • USVN — утилита для создания и управления доступом к репозиториям, специализирована под SVN,
    • ViewVC,
    • WebSVN,
    • SVNManager — PHP-утилита для управления репозиториями (создание, удаление, загрузка и выгрузка; управление пользователями и группами),
    • Submin — утилита для управления репозиториями и пользователями, включая управление контролем доступа к отдельным каталогам в репозитории,
    • cSvn — кросс-платформенный клиент Subversion наC.
  • Сравнительная таблица: веб-интерфейсы:

Наименование

Описание

Язык

БД

Лицензия

Сайт

Обновление

Версия

Trac

инструмент, основанный на технологии Wiki

Python

SQLite, PostgreSQL, MySQL и MariaDB

Модифицированная лицензия BSD

trac.edgewall.orgАрхивная копия от 8 апреля 2013 наWayback Machine

21.06.2017

1.2.2

Redmine

дополнительно отслеживает ошибки

Ruby

MySQL, PostgreSQL, SQLite, Oracle.

GNU General Public License

redmine.orgАрхивная копия от 27 апреля 2011 наWayback Machine

09.12.2018

4.0.0

USVN

утилита для создания и управления доступом к репозиториям, специализирована под SVN

PHP

MySQL, SQLlite

CeCill (GPL совместимая лицензия).

www.usvn.infoАрхивная копия от 12 мая 2011 наWayback Machine

13.01.2012

1.0.6

ViewVC

без управления пользователями, не требует поддержки DAV web-сервером.

Python

MySQL

Two-clause Berkeley-style

www.viewvc.orgАрхивная копия от 4 мая 2011 наWayback Machine

02.12.2010

1.1.8

WebSVN

интерфейс просмотра к SVN

PHP

XML

GNU GPL

websvn.tigris.orgАрхивная копия от 12 июня 2006 наWayback Machine

12.10.2010

2.3.2

SVNManager

утилита для управления репозиториями (создание, удаление, загрузка и выгрузка; управление пользователями и группами)

PHP

MySQL or SQLite

svnmanager.sourceforge.netАрхивная копия от 30 апреля 2011 наWayback Machine

28.01.2012

1.09

Submin (MIT)

утилита для управления репозиториями и пользователями, включая управление контролем доступа к отдельным каталогам в репозитории

Python

MIT/XАрхивная копия от 6 июня 2011 наWayback Machine

24.12.2012

2.1

cSvn

web-интерфейс просмотра Subversion-репозиториев

C

RADIX-1.0

csvn.radix.proАрхивная копия от 16 марта 2022 наWayback Machine

17.11.2020

0.1.3

Примечания

[править |править код]
  1. https://subversion.apache.org/docs/release-notes/release-history.html
  2. Sahlberg D.Apache Subversion 1.14.5 released (англ.) — 2024.
  3. 123456The subversion Open Source Project on Open Hub: Languages Page — 2006.
  4. https://projects.apache.org/json/projects/subversion.json
  5. 1234Free Software Directory
  6. http://subversion.tigris.org/license-1.html
  7. Английское словоsubversion можно перевести двояко — как «свержение» (subversion) и как «подверсия» (sub-version)
  8. По названиюпрограммы-клиента длякомандной строки, входящей в состав пакета
  9. Apache Trademark Listing  (неопр.). Дата обращения: 10 октября 2015. Архивировано 7 октября 2015 года.
  10. Subversion FeaturesАрхивная копия от 8 апреля 2011 наWayback Machine (англ.)
  11. The Risks of Distributed Version ControlАрхивная копия от 15 июля 2011 наWayback Machine Бен Коллинз-Сассман  (англ.)
  12. CVS is out, Subversion is inАрхивировано 25 марта 2010 года. (англ.) Red Hat magazine, август 2005 г.
  13. CVS — sourceforgeАрхивировано 10 июня 2010 года.
  14. CVS — система управления версиями  (неопр.). Дата обращения: 30 июня 2010. Архивировано 8 июля 2010 года.
  15. HEADS UP: FreeBSD src repo transitioning to git this weekend (англ.). lists.freebsd.org (17 декабря 2020). Дата обращения: 22 декабря 2020. Архивировано 18 декабря 2020 года.
  16. The Forrester Wave: Software Change and Configuration Management, Q2 2007  (неопр.). Forrester Research. Архивировано изоригинала 25 августа 2011 года.
  17. Popularity contest statistics for bzr, git, git-core, mercurial, subversion  (неопр.). Дата обращения: 24 июня 2010. Архивировано 6 апреля 2014 года.
  18. Архивированная копия  (неопр.). Дата обращения: 24 июня 2010. Архивировано 17 июля 2011 года.
  19. см.http://subversion.apache.org/docs/Архивная копия от 17 июня 2010 наWayback Machine  (англ.)
  20. Ben Collins-Sussman, Brian W. Fitzpatrick & C. Michael Pilato. Version Control with Subversion (англ.). Дата обращения: 27 ноября 2019. Архивировано 8 августа 2010 года.
  21. Бен Коллинз-Сассман, Брайан У. Фитцпатрик, К. Майкл Пилато. Управление версиями в Subversion  (неопр.). Дата обращения: 27 ноября 2019. Архивировано 18 ноября 2019 года.
  22. Бен Коллинз-Сассман, Брайан У. Фицпатрик, К. Майкл Пилато. История Subversion /Управление версиями в Subversion  (рус.) (2007). — Для Subversion 1.4. Дата обращения: 21 июля 2010. Архивировано изоригинала 25 августа 2011 года.
  23. Список измененийАрхивная копия от 18 июня 2010 наWayback Machine (англ.)
  24. Goliath Business NewsАрхивировано 5 декабря 2008 года.
  25. Subversion 1.1 Release Notes  (неопр.). Дата обращения: 18 июня 2010. Архивировано 17 июня 2010 года.
  26. Subversion 1.2 Release Notes  (неопр.). Дата обращения: 18 июня 2010. Архивировано 17 июня 2010 года.
  27. Subversion 1.3 Release Notes  (неопр.). Дата обращения: 19 июня 2010. Архивировано 17 июня 2010 года.
  28. Subversion 1.4 Release Notes  (неопр.). Дата обращения: 18 июня 2010. Архивировано 17 июня 2010 года.
  29. Subversion 1.5 Release Notes  (неопр.). Дата обращения: 18 июня 2010. Архивировано 2 июля 2016 года.
  30. Subversion 1.6 Release Notes  (неопр.). Дата обращения: 18 июня 2010. Архивировано 17 июня 2010 года.
  31. Subversion переведена под контроль Apache Software FoundationАрхивная копия от 23 февраля 2010 наWayback Machine, nixp.ru
  32. Subversion & the Move to the Apache Software Foundation (недоступная ссылка), (видеообращение президента Subversion Corporation)
  33. Apache Subversion 1.7 Release Notes  (неопр.). Дата обращения: 12 октября 2011. Архивировано 12 октября 2011 года.
  34. 12Subversion 1.8 Release Notes  (неопр.). Дата обращения: 9 июля 2013. Архивировано 10 июля 2013 года.
  35. работа ссимвольными ссылками поддерживается только в рабочих копиях подUNIX-системами
  36. 12Ветви и метки в Subversion не являются независимым измерением хранилища. См.The Key Concepts Behind BranchingАрхивная копия от 5 октября 2015 наWayback Machine
  37. Терминыхранилище ирепозиторий являются синонимами.
  38. Глава 5. Администрирование хранилищаАрхивная копия от 9 ноября 2017 наWayback Machine в книге «Управление версиями в Subversion»
  39. Здесь перечислены операции именно с точки зренияфайловой системы хранилища. В рабочей копии действия над объектами несколько иные. Однако изменения в рабочей копии, будучи зафиксированными, вызовут в хранилище описанные здесь действия. Например, командаsvn move в рабочей копии произведёт операцииD,A+ в хранилище.
  40. Структура проектов на C++ с использованием Subversion и Mxx_ruАрхивная копия от 19 февраля 2008 наWayback Machine.
  41. Хранение сложных проектов в репозитории и установка tag’ов на несколько проектов сразуАрхивная копия от 4 августа 2008 наWayback Machine.
  42. Inter-File Branching in PerforceАрхивировано 14 июля 2007 года.
  43. Path-Based Authorization  (неопр.). Дата обращения: 27 мая 2008. Архивировано 7 октября 2008 года.
  44. Типовые примерыАрхивная копия от 3 декабря 2008 наWayback Machine, раздел в книге «Управление версиями в Subversion, версия 1.4»
  45. Bubble-Up MethodАрхивная копия от 17 июня 2010 наWayback Machine (англ.)
  46. В CVS каталог можно переместить прямо в хранилище средствамифайловой системы, при этом файлы в нём не потеряют историю. Однако эта модификация подействует на все ревизии и ветви файлов в этого каталога (поскольку в CVS каталоги вообще не имеют версионной информации).
  47. Subversion FAQ  (неопр.). Дата обращения: 14 апреля 2010. Архивировано 15 апреля 2010 года.
  48. Runtime Configuration Area. Customizing Your Subversion Experience  (неопр.). Дата обращения: 16 сентября 2010. Архивировано изоригинала 25 августа 2011 года.
  49. Copy/move-related improvements in Subversion 1.5  (неопр.). Дата обращения: 24 июня 2008. Архивировано 24 июня 2008 года.
  50. Merge tracking (foundational)  (неопр.). Дата обращения: 24 июня 2008. Архивировано 24 июня 2008 года.
  51. Subversion merge reintegrateАрхивная копия от 31 августа 2009 наWayback Machine (англ.)
  52. svn obliterate  (неопр.). Дата обращения: 21 июля 2008. Архивировано 22 ноября 2002 года.

Ссылки

[править |править код]
Subversion:

Перейти к шаблону «Системы управления версиями»
Только локальные
Клиент-серверные
Распределённые
Перейти к шаблону «Схемы URI»
СхемыURI
Официальные
Неофициальные
✰
Эта статья входит в числохороших статей русскоязычного раздела Википедии.
Источник —https://ru.wikipedia.org/w/index.php?title=Subversion&oldid=136647485
Категории:
Скрытые категории: