|
|
| Строка 1: |
Строка 1: |
| − | <!--
| + | partially intergovernmental began indicates evidence measurements |
| − | {{Карточка программы
| + | |
| − | | 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]]}} — свержение.</ref> ('''SVN''')
| + | |
| − | — [[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 — централизованная система (в отличие от распределённых систем, таких, как [[Git]] или [[Mercurial]]), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом [[сервер (аппаратное обеспечение)|сервер]]е.
| + | |
| − | | + | |
| − | Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют [[файл]]ы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и публикуют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель ''Копирование-Изменение-Слияние''. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель ''Блокирование-Изменение-Разблокирование''.
| + | |
| − | | + | |
| − | При сохранении новых версий используется [[Дельта-кодирование|дельта-компрессия]]: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.
| + | |
| − | | + | |
| − | При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент 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'', см. [[Система управления версиями#Словарь|словарь]]), как таковых. Вместо них используется иерархия директорий — для метки создаётся отдельная директория (как и для ветви). Метка — это ветвь, в которой по договоренности больше не делают изменений.
| + | |
| − | |Метки поддерживаются
| + | |
| − | |-
| + | |
| − | !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)]]
| + | |
