Svn что это такое
Subversion vs. Git: Развенчивание мифов о развенчивании мифов
Я относительно недавно сменил работу, попал в компанию, где используется svn, но переход на git часто всплывает в обсуждениях.
Однажды я стал свидетелем обсуждения этой темы. Коллеги обсуждали тот самый сайт и пришли к выводу, что «меняем шило на мыло».
В этом диалоге я был невольным слушателем, но что там за сайт и его аргументы меня заинтересовали. Пошел разбираться.
Начнем с первого заявления
The particular delta compression algorithms used in both version control systems differ in many details, but in general Subversion and Git store data in the same way. This results in the fact that Subversion and Git repositories with equivalent data will have approximately the same size. Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files).
Ниже есть пример, где они сравнивают размер репозитория. Вывод – разница не существенна.
Меня смутило различное число коммитов, и фактически разные первоисточники(кто знает, как они там синхронизируют эти репозитории). Так же меня не устроил уровень детализации описания процесса получения этих чисел.
Итак, начнем свой эксперимент!
Получаем svn репозиторий
У нас локальная копия всего репозитория в формате svn. Это папка размером 213 МБ, которая содержит 79758 файлов и 88 папок.
На этот момент в репозитории насчитывается 39864 коммита. Рабочая копия проекта состоит из 1701 файла и 160 папок.
Начинаем миграцию в гит
Этот этап был самым длительным, затянулся более чем на сутки (примерно 32 часа). В результате имеем git репозиторий — копия оригинального svn репозитория(не совсем копия, но для нас различия не существенны).
Здесь я сделал небольшую глупость, стоило бы создавать репозиторий без рабочей копии, но еще раз ждать более суток я был не готов.
Итак, папка git_from_svn/.git: 208 МБ содержит 7841 файлов и 509 папок. На данном этапе действительно можно говорить о незначительном перевесе в пользу git, видимо как раз на этом этапе и остановились те, кто ведет сайт. Но ведь у гита есть 2 формата хранения: “loose” object и “packfile».
Посмотрим, что же мы имеем:
count: 6826
size: 30.21 MiB
in-pack: 249852
packs: 25
size-pack: 145.51 MiB
prune-packable: 73
garbage: 0
size-garbage: 0 bytes
То есть у нас есть множество пакетов и 6826 (30.21 МБ) не сжатых объектов.
Оптимизируем хранение
count: 0
size: 0 bytes
in-pack: 256605
packs: 1
size-pack: 104.54 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes
Размер самой папки «.git» получается 136 МБ(945 файлов, 255 папок). Мне кажется такое преимущество уже сложно назвать незначительным.
Еще подчистим
Но и это еще не все, если избавиться от наследия svn — пушнуть это все в bare репозиторий получаем еще интересней картинку: 106 MБ, 19 файлов, 8 папок.
Соберем все вместе
svn — 213 MБ (79 758 файлов, 88 папок)
svn(после pack) — 214 MБ (4 644 файлов, 89 папок) (дополнение после публикации)
git svn — 208 MБ (7 841 файлов, 509 папок)
git svn(pack) — 136 MБ (945 файлов, 255 папок)
git bare(pack) — 106 MБ (19 файлов, 8 папок)
Мне кажется на этом этапе развенчивание мифа можно считать развенчанным(утверждение на сайте опровергнуто).
Еще стоит упомянуть, что loose объекты у вас все же будут, предназначены они для повышения производительности работы с часто используемыми файлами. Обычно в таком формате будут храниться файлы из веток, в которых сейчас активно идет работа. Их количество можно регулировать через конфигурационные файлы.
Идем дальше
Branches in Subversion are implemented with Copy-On-Write strategy (referred to as ‘Cheap Copies’ in the svnbook). No matter how large a repository or project is, it takes a constant amount of time and space to make a branch. In fact, Subversion branches are extremely cheap beginning with version 1.0 and you can branch even for small bugfixes in a very busy and large project.
И эксперимент это «подтверждающий».
Вывод – создание бранчи происходит быстрей чем вы глазом моргнуть успеете. Мне показалось, что если вся операция занимает меньше 0,01 секунды то тут и сравнивать нечего. Но почему-то на заявление о дороговизне бранчей в svn, сайт проверил только их создание. Но есть другие операции, например клонирование( или svn checkout). В этом эксперименте все происходит локально, возможное влияние сети исключено.
Первый эксперимент – клонирование
Git проиграл. Но здесь стоит учесть, git получил всю историю, а svn — одну ревизию.
Второй эксперимент – смена бранчи
Здесь все наоборот, при этом на одном переключении мы отыграли половину от потери при клонировании.
На этом я пожалуй закончу. Пойду обсуждать эти результаты с сотрудниками.
PS: Несмотря на то, что посыл этой заметки банален «не стоит доверять непроверенным источникам в интернете», но, оказывается, есть еще люди, не развившие достаточный уровень здорового скептицизма.
Установка и настройка SVN (сервер+клиент)
По просьбам трудящихся, а так же учитывая, что есть статья по установке SVN (правда +Trac) под Linux, решил написать краткое описание установки и настройки SVN для Windows.
Ничего нового для людей, хорошо знающих и работающих с SVN, здесь не будет. Цель статьи — помочь некоторому проценту новичков, пребывающих на Хабре, таки осилить изучение этой системы контроля версий.
С самого начала сообщаю, что для SVN есть подробное руководство. Называется оно svn-book и доступно на сайте и идет вместе с CollabNet Subversion-server. Так же про установку и настройку svnserv с Apache есть описание в учебнике по TortioseSVN (довольно хорошая подробная помощь на русском).
На самом деле SVN-клиент может отлично работать и без сервера. Репозиторий (хранилище кода) можно создать в любом каталоге на собственном HDD, или в сетевом каталоге. Сервер требуется лишь для удаленного доступа к репозиторию, не больше. Локальный репозиторий годится, если над проектом работает один человек и ему просто нужна система контроля версий своего приложения и бэкапы.
Если работа ведется в команде или требуется удаленный доступ к репозиторию (через Интернет, например), нужно устанавливать SVN-сервер. Он может работать самостоятельно, либо через веб-сервер Apache. В первом случае доступ к репозиториям будет по протоколу svn://, во втором — http(s)://. Доступ через веб-сервер нужен при проблемах с файрволом, когда он пропускает только HTTP-трафик, а так же для работы некоторых утилит-примочек к SVN-серверу.
Установка сервера
Самую свежую версию svn-cервера всегда можно найти на сайте subversion.tigris.org. Чистый svn-сервер без Apache в комплекте, и без визуальных примочек доступен только для версии 1.4.6, в то время как текущая версия 1.5.0. Для версии 1.5.0 есть выбор между CollabNet Subversion-server-1.5.0 (
5 MB). Первый идет в комплекте с Apache, второй — с Apache и плагином для Windows Management Console. Так же для VisualSVN есть платная возможность интеграции с Visual Studio.
A. Установка и настройка сервера VisualSVN (svn-сервер + Apache + консоль управления) самая простая. Эту версию нельзя установить без Apache.
1) Скачиваем файл VisualSVN-Server-1.5.1.msi или новее. Запускаем установку.
2) В мастере установки указываем, использовать ли для доступа HTTPS, либо просто HTTP. Указываем порт для прослушивания по выбранному протоколу и способ аутентификации. Так же указываем каталог, в котором будут храниться репозитории.
3) После установки открываем Management Console (через Пуск, например) и создаем пользователей и репозитории.
Теперь ваши репозитории доступны через выбранный протокол (HTTP или HTTPS) по указанному при установке хосту: порту (например, localhost:8443/svn/). Их можно просматривать как из браузера (через xsl), так и из SVN-клиета.
Работа с сервером VisualSVNбезусловно самая простая.
B. Установка CollabNet Subversion Server (svn-сервер + Apache опционально).
1) Скачиваем файл CollabNetSubversion-server-1.5.0-23.win32.exe или версию новее. Запускаем его на установку.
2) Шаг Choose Components. Устанавливаем флажок SVNSERVE в любом случае. Если требуется установить так же Apache для SVN, устанавливаем флажок напротив него.
3) На шаге sunserve Configuration устанавливаем порт для sunserve (по умолчанию 3690, менять его смысла нет, если он не занят) и путь к репозиториям (каталог, где вы будете создавать отдельные репозитории в виде подкаталогов).
4) Затем настраивается Apache: хост/порт, путь к репозиториям (тот же, что и для svnserve) и префикс для URL (http://host:port/prefix). Префикс нужен на случай, если Apache будет использоваться не только для обслуживания SVN.
После установки появятся две новых службы Windows: Subversion Server (наш svnserv.exe) и Apache2.2 (если он был включен при установке). Чтобы все заработало их нужно запустить.
С. Установка svnserve 1.4.6 (чистый svn-сервер).
Именно эту работу (если не считать установку Apache) сделал за вас установщик CollabNet Subversion Server. В случае установки svnserve 1.4.6 доступ к репозиторию будет только по протоколу svn://.
D. Создание репозитория. Выделяю этот пункт отдельным разделом. Если в VisualSVN создание репозитория производится кликом мыши, то для svnserve (в том числе в версии от CollabNet) репозиторий создается из консоли. В поставке snv-сервера есть файл snv-install-folder\bin\svnadmin.exe. Если путь к snv-install-folder\bin еще не прописан в PATH, сделайте это.
Чтобы создать репозиторий, откройте консоль (cmd) и перейдите в каталог для хранения репозиториев, который вы указывали при установке (CollabNet) или создании сервиса (svnserve 1.4.6). Создайте новый пустой подкаталог (например, example-repository). В консоли выполните команду: svnadmin create example-repository. В только что созданном каталоге появится структура файлов svn. В них есть много полезных «штук», о которых можно почитать в svn-book и учебнике.
В подкаталоге conf можно настроить основные параметры репозитория. Прежде всего требуется закрыть доступ в репозиторий кому-попало. В файле svnserve.conf раскомментируем строки
# anon-access = read
# auth-access = write
Не забудьте убрать так же пробел после #, т.к. иначе будет ошибка чтения конфига. anon-access определяет доступ анонимным пользователям, auth-access — зарегистрированным. Они могут принимать значения «write», «read» и «none». Обычно anon-access = none и auth-access = write.
Далее надо раскомментировать # password-db = passwd, а в файл passwd в этом же каталоге добавить строку user = password.
Для начала такое определение доступа годится, но в последствии конечно пароли надо шифровать (читаем svn-book).
На этом установка сервера закончена и можно установить клиент.
Установка клиента.
Некоторые профессионалы предпочитают работать с консолью. Наверное это не самый удобный способ, особенно для новичков, поэтому рассматривать его не будем. Другие работают с SVN через плагины к своим IDE. Это самый лучший способ, но поскольку разных IDE много и плагинов к ним тоже, в этой статье работу с ними не описываем.
Самым популярным и признанным клиентом SVN под Windows является TortoiseSVN. После его установки вы не получите отдельной программы, которую можно «классически запустить», клиент встраивается в проводник Windows, а команды для него доступны из контекстного меню файла (в т.ч. и в Total Commander).
Описывать установку клиента нет никакого смысла, там все элементарно просто.
О том, как работать с TortoiseSVN, подробно расписано в руководстве TortoiseSVN Клиент Subversion для Windows.
Дублировать это подробное руководство, конечно, желания нет, но все же super-fast-start work with tsvn опишу.
1) Для просмотра любого репозитория после установки TortoiseSVN вызовите контекствное меню на любом файле в системе, выберите меню TortoiseSVN→Repo-browser. В открывшемся окошке введите адрес репозитория с протоколом (например, localhost:8443/svn/test или svn://someserver:3690/proj1/trunc). Откроется окно просмотра репозитория (с помощью кнопки напротив строки адреса можно выбрать, какую ревизию просмотреть; HEAD — это последняя ревизия).
2) Для создания локального репозитория (не используя сервер) запускается пункт меню TortoiseSVN→Create repository here. на нужном каталоге. В Repo-browser такой репозиторий доступен по протоколу file:///.
3) Для скачки себе версии из существующего репозитория запускается пункт меню TortoiseSVN→SVN Checkout на каталоге, в который сольется версия.
4) Если вы еще не использовали SVN и хотите залить на сервер свою текущую версию исходников, запустите пункт меню TortoiseSVN→Import. на каталоге, в котором лежит версия (при этом не забудьте, что разрабатываемую ветку надо лить в trunk).
5) TortoiseSVN→Export. используется для получения чистой версии исходников из репозитория (без служебных файлов контроля версий).
6) Если контекстное меню вызвать на каталоге, который является локальной (рабочей) копией репозитория, контекстное меню значительно расшириться. Например, появятся пункты Update (слить последние изменения с сервера) и Commit (закачать ваши изменения на сервер).
На последок рекомендую почитать интересную серию статей Работа с Tortoise SVN.
Svn что это такое
Subversion [1] — свободная централизованная система управления версиями, созданная в 2000 г. компанией CollabNet Inc.
Subversion используется многими сообществами разработчиков открытого программного обеспечения. В их числе такие известные проекты как KDE, GCC, Free Pascal, Ruby, FreeBSD. Хостинг Subversion для проектов с открытым кодом предоставляют Google Code и BountySource. Также Subversion широко используется в корпоративной сфере.
В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)». [4]
Subversion часто называют «SVN», по названию клиентской программы, входящей в её дистрибутив.
Содержание
История
Разработка Subversion была начата в 2000 году по инициативе и при финансовой поддержке CollabNet, Inc. Инициаторы проекта хотели создать свободную систему управления версиями, в основном похожую на CVS, но лишённую её ошибок и неудобств. В то время не существовало лучших программ этого класса со свободной лицензией, CVS была стандартом де-факто среди разработчиков свободного программного обеспечения. Выбрав её за основу, разработчики Subversion надеялись упростить разработку за счёт использования уже проверенных концепций и в то же время облегчить переход на новую систему многочисленным пользователям CVS. [5]
31 августа 2001 года, спустя четырнадцать месяцев с начала работы, команда разработчиков перешла с CVS на Subversion для управления собственным исходным кодом — Subversion стала «самодостаточной».
23 февраля 2004 года вышел релиз 1.0.0. [6] К этому времени Subversion уже использовалась примерно на 1400 серверах с открытым доступом. [7]
29 сентября 2004 года появился релиз 1.1.0. Среди основных нововведений — новый формат хранилища на основе обычных файлов (FSFS), в дополнение к существовавшему ранее (с использованием Berkeley DB). [8]
В релизе 1.2.0 (21 мая 2005 г.) была добавлена возможность блокировки файлов. [9] Это позволило улучшить поддержку клиентов WebDAV/DeltaV, в том числе, реализовать автоматическое создание новых версий при редактировании файлов с помощью таких клиентов. Начиная с этого релиза Subversion по умолчанию использует FSFS для новых хранилищ.
Релиз 1.4.0 (10 сентября 2006) поддерживает работу с BerkeleyDB 4.4 и может использовать её функции самовосстановления. [10] Ранее при сбоях Subversion хранилище, использующее BerkeleyDB, могло остаться в «заклиненном» состоянии и требовалось вмешательство администратора для восстановления работы системы (при использовании FSFS этой проблемы нет).
Релиз 1.6.0 (20 марта 2009) [12] : улучшения поддержки svn:externals, обнаружение «конфликтов деревьев» (англ. tree conflict ), улучшение эффективности хранения данных в репозитории и другие.
Общие сведения
Возможности
Модель работы
Subversion — централизованная система (в отличие от распределённых систем, таких, как Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.
Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель Копирование-Изменение-Слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель Блокирование-Изменение-Разблокирование.
При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.
При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, то автоматически создаётся новая версия.
Типы репозиториев
Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации [14] (Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок), каждая из них обладает своими преимуществами и недостатками. Считается, что FSFS легче правильно настроить, она требует меньшего внимания от администратора. Кроме того, до релиза 1.4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном (англ. wedged ) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS.
Доступ к репозиторию
Начиная с версии 1.4 Subversion предоставляет следующие способы доступа к репозиториям:
Все эти способы могут быть использованы для работы с репозиторями обоих типов (FSFS и Berkeley DB). Для доступа к одному и тому же репозиторию могут одновременно использоваться разные способы.
Основные концепции
Файловая система
С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. Объекты в хранилище (файлы и директории) идентифицируются двумя «координатами»: именем и номером ревизии. Для однозначной адресации объекта необходимо указание обоих параметров. При необходимости указания на конкретную ревизию объекта используется запись вида: имя@ревизия, например, /main.c@29 — файл /main.c в ревизии 29. Такое указание ревизии, используемое для уточнения имени, называется стержневая ревизия (англ. peg revision ).
На рисунке 1 показано графическое представление файловой системы: вертикальная ось соответствует множеству имён, горизонтальная — множеству ревизий. Другими словами, хранилище представляет собой массив мгновенных снимков (ревизий) дерева файлов и директорий, индексируемый номером ревизии. Каждый такой снимок — обычная (одномерная) файловая система.
Имена файлов
Имя объекта файловой системы в Subversion образуется по тем же правилам, что и в UNIX-подобных операционных системах: существует только одна корневая директория, элементы пути разделяются косой чертой «/». Объектами файловой системы являются файлы и директории (а также символические ссылки, которые эмулируются из обычных файлов путем установки атрибута svn:special).
Номера ревизий
Номер ревизии в Subversion — это натуральное число, адресующее номер состояния хранилища в процессе изменения содержащихся в нём данных. Каждая успешная фиксация изменений порождает ровно одну новую ревизию в хранилище, то есть N-я ревизия — это состояние хранилища после N-й фиксации.
В Subversion ревизия характеризует состояние не отдельного файла, а всего хранилища в целом. Например, ревизия 32 (обведено пунктиром на рисунке) — это состояние трёх файлов и двух директорий, существовавших в хранилище на тот момент.
Номер ревизии является аналогом времени в том смысле, что меньшие номера ревизий соответствуют более ранним состояниям хранилища, а бо́льшие — поздним:
Номер ревизии можно рассматривать как некую временну́ю отметку в истории хранилища. Более того, с каждым номером ревизии связано абсолютное значение времени, когда эта ревизия была сделана (свойство svn:date). Однако указание номера ревизии удобнее, чем указание времени, так как нет путаницы с часовыми поясами, запись номера короче и номер ревизии не может быть изменён.
Оперативная и стержневая ревизии
Номер ревизии используется в двух различных контекстах:
Ревизия называется оперативной, если она указывается как ревизия или диапазон ревизий, к которому должна быть применена команда, например:
В данном примере выполняется команда svn log для диапазона ревизий 199:230, который и является диапазоном оперативных ревизий.
Однако указание только оперативной ревизии иногда может неоднозначно указывать на объекты хранилища. Например, в ситуации, показанной на рисунке 2, возникает неоднозначность при выполнении следующей команды:
В команде указан диапазон оперативных ревизий (29:33), но области, выделенные на рисунке голубым и зеленым фоном, в равной степени можно считать историей файла /bar.txt в диапазоне ревизий 29:33. В подобных случаях необходимо указывать еще и стержневую ревизию для разрешения неоднозначности. Стержневая ревизия — это номер ревизии, указанный в дополнение к URL объекта файловой системы: пара URL + стержневая ревизия всегда однозначно идентифицирует объект (файл или директорию). Между URL и номером стержневой ревизии ставится символ «@», то есть используется запись вида URL@ревизия. Команда применяется к той единственной цепочке состояний, которой принадлежит указанная пара URL@ревизия. В приведенном ниже примере первая команда выведет историю, выделенную на рисунке голубым фоном, а вторая — историю, выделенную зеленым фоном:
В качестве стержневой ревизии следует указывать как можно более позднее состояние интересующего объекта. Причина этого в том, что цепочка состояний однозначно отслеживается «назад», но не «вперёд». Например, URL со стержневой ревизией http://some.path/foo.txt@31 принадлежит двум цепочкам состояний (выделены соответственно зеленым и серым фоном). Из этих двух цепочек указанный URL адресует серую цепочку, то есть при движении «вперёд» от стержневой ревизии операции копирования игнорируются.
Операции над файловой системой
Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции [15] (смотри также рисунок 1). В скобках указано краткое именование операции в обозначениях команды svn status.
Фиксация изменений
Рабочая копия
Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория. Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.
Рабочая копия является самодостаточной в том смысле, что Subversion не хранит каких-либо данных, относящихся к рабочей копии, вне её. Поэтому, имея одну рабочую копию, можно сделать ещё несколько копий без затрат сетевого трафика. В служебных директориях рабочей копии, помимо прочего, хранится (в директориях .svn/text-base/) так называемая чистая копия (англ. pristine copy ) — файлы рабочей копии в неизменённом виде, как они были извлечены из хранилища. Наличие чистой копии позволяет быстро и без обращения к хранилищу выполнять операции просмотра и отката локальных изменений. Однако размер рабочей копии на диске примерно в два раза больше (данные + чистая копия данных), чем размер самих данных. Такой подход обусловлен тем, что дисковые ресурсы дешевле и доступнее, чем ресурсы сети передачи данных.
Как правило, создание рабочей копии является первым и необходимым этапом для фиксации локальных изменений, поскольку зафиксировать в хранилище можно только изменения, сделанные в рабочей копии. Исключением являются операции, которые могут быть выполнены прямо в хранилище без создания рабочей копии.
Транзакции
Локальные и удаленные формы команд
Все команды клиента Subversion можно разделить на следующие группы:
Структура хранилища
Структура проекта в хранилище
Subversion не накладывает каких-либо ограничений на структуру директорий в файловой системе хранилища, она может быть какой угодно в рамках правил именования объектов файловой системы. Тем не менее, существуют некоторые общепринятые «правила хорошего тона». В простейшем случае в корневой директории файловой системы имеются как минимум три директории:
Директория /trunk содержит основную линию разработки проекта, /branches содержит все ветви, /tags содержит все метки. Такая структура удобна для хранилища, содержащего только один проект. Если проектов несколько, то более удобна следующая структура:
Другим способом хранения нескольких проектов является создание нескольких хранилищ. В разных хранилищах следует располагать проекты, которые никак не связаны между собой, поскольку между хранилищами нельзя будет выполнить операции копирования, перемещения и слияния. Несколько хранилищ можно при необходимости объединить в одно с сохранением истории ревизий (путём импорта командой svnadmin load с параметром --parent-dir).
Ветви
Subversion использует «файловую» модель (такую же, как и в [18] ) для реализации ветвей и меток, то есть ветвь является обычной директорией (можно также сделать ветвь из одного файла, а не директории). Новая ветвь создаётся командой svn copy. Ветвь может быть создана в любой директории хранилища, однако имеет смысл придерживаться некоторых соглашений о том, где создавать новые ветви. Более подробная информация о ветвях приведена в разделах Ветвление и Слияние.
Метки
Создание метки также производится командой svn copy, то есть технически не отличается от создания ветви. Отличие только в способе использования: предполагается, что никто не будет изменять данные в метке (фиксировать в нее изменения). Например, на рисунке 1 метка создана в ревизии 29: директория /trunk из ревизии 27 скопирована под именем /tags/R1. Теперь, если не изменять данные в директории /tags/R1, то она навсегда останется точной копией директории /trunk@27, то есть будет меткой.
Концепция меток, используемая в Subversion, отличается от концепции меток в других системах управления версиями. Обычно метка является символическим именем, которое адресует набор файлов и их состояние. В Subversion метка копирует набор файлов и их состояние. Метки-копии в Subversion имеют свои достоинства и недостатки:
Свойства (properties)
Одной из важных возможностей Subversion является поддержка свойств, то есть текстовых пар имя=значение, которые могут быть установлены для объектов в хранилище. Свойства используются в двух различных контекстах: для объектов файловой системы и для ревизий.
Свойства объектов файловой системы
Каждому файлу или директории в хранилище может быть присвоен набор свойств. Изменения свойств сохраняются в истории так же, как и изменения в файловой системе. Пользователи могут устанавливать свойства с любыми именами; существует также предопределённый набор служебных свойств, которые используются клиентской программой Subversion (имена служебных свойств имеют префикс ‘svn:’).
Свойства файлов
Свойства директорий
Свойства ревизий
Второй тип объектов, для которых существуют свойства, — это сами ревизии. В этом случае имена свойств также могут быть любыми; некоторые свойства с префиксом «svn:» имеют специальное значение. Отличие свойств ревизий от свойств объектов файловой системы в том, что для первых понятие истории версий не применимо (поскольку конкретное значение свойства приписано одной ревизии). Другими словами, свойства ревизий можно изменить, но старое значение при этом теряется. По умолчанию изменение свойств ревизий запрещено; для разрешения администратор должен создать скрипт (англ. hook ) обработки события pre-revprop-change.
svn:date Дата и время создания ревизии. svn:author Имя пользователя, который зафиксировал изменения, вошедшие в эту ревизию. svn:log Описание изменений, зафиксированных в этой ревизии (текст, введенный пользователем при фиксации изменений).
Как правило, свойства ревизий изменяются только администратором хранилища в целях исправления некорректных данных. Например, если пользователь забыл указать текстовое описание при фиксации своих изменений, то администратор может создать это описание путем редактирования свойства svn:log.
Использование Subversion
Простейший рабочий цикл
Простейший цикл работы с Subversion включает следующие этапы:
Ветвление
Ветвление является важным аспектом работы систем управления версиями, поскольку типичные приемы [20] управления версиями (по крайней мере, при разработке программного обеспечения) подразумевают использование ветвей. Subversion обладает достаточно развитыми возможностями для ветвления и слияния.
На рисунке 3 условно показан пример эволюции ветвей в хранилище. Зелёным цветом показана основная линия разработки проекта (англ. mainline, trunk ), жёлтым — ветви, синим — метки, пурпурным — ветвь, разработка которой прекращена. Красными стрелками показаны слияния изменений.
Создание ветвей
Новая ветвь (а также метка) создаётся командой svn copy, которая создаёт в хранилище копию с наследованием истории ревизий источника (операция A+). Для создания ветвей всегда следует использовать «удаленную» форму команды svn copy, например:
Полученная копия будет ветвью (или меткой, в зависимости от способа работы с ней). В дальнейшем изменения, сделанные на ветви, могут быть внесены в источник, из которого была создана эта ветвь, такое распространение изменений называется слияние (англ. merge )
Работа с ветвями
В целом работа на ветви не отличается от работы на основной линии разработки (trunk). Специфичные команды требуются только для действий, в которых задействовано более одной ветви. К таким командам относятся (помимо команды создания ветви svn copy):
Как правило, полный цикл работы с ветвями включает следующие этапы:
Слияние
Копирование изменений между ветвями
Слияние в 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 по всем параметрам, кроме поддержки меток в общепринятом смысле (то есть меток, адресующих объекты файловой системы).
Миграция с CVS на Subversion
Преобразование репозитория
Отличия в использовании
Переименование
Пользователи, перешедшие с CVS на Subversion, часто выполняют переименование файлов и директорий неправильным способом. В CVS не существует иного способа изменения имени, кроме как удалить объект со старым именем и добавить объект с новым именем. Аналогичные (неправильные!) действия в Subversion выполняются парой команд (или аналогичными действиями через графический клиент):
Данный способ переименования неправильный потому, что новый объект, добавленный командой svn add, не имеет истории (поскольку он добавлен как новый), то есть полностью теряется связь со старым именем и его историей ревизий. Правильный способ переименования объектов в Subversion:
При этом объект со старым именем также удаляется, но объект с новым именем копируется со старого с сохранением истории. При просмотре истории ревизий переименованного объекта будет виден факт копирования, а также вся история ревизий до копирования.
Все сказанное в равной степени относится и к копированию: следует использовать именно копирование (svn copy), а не добавление нового экземпляра объекта (svn add).
Адресация состояния хранилища
В CVS для указания на некоторое состояние хранилища (например, стабильное состояние исходного кода) используются метки. Использование меток в Subversion подобным образом вызовет некоторые неудобства (прежде всего, невозможность дальнейшей работы прямо от метки). Правильным способом указания состояния в Subversion является номер ревизии.
Внутренняя структура
Уровни
Subversion спроектирован как набор библиотек, разделённых на несколько уровней. Каждый из них выполняет конкретную задачу и позволяет разработчикам создавать свои собственные инструменты, в зависимости от сложности и задачи.
Недостатки
Subversion не всегда может правильно обработать операции переименования файлов, если одновременно с переименованием изменяется и содержимое файла. Проблемы могут также возникнуть, если файл, переименованный в локальной копии, кто-то другой изменил в хранилище. Часть этих проблем исправлена в версии 1.5, однако это решение пока не полное. [24]
Также слабым местом Subversion считают операции слияния веток. До версии 1.5 все такие операции пользователям приходилось отслеживать вручную, с помощью подробных записей в журнале изменений. В текущей версии появилась базовая поддержка автоматического отслеживания слияний, которую разработчики планируют улучшить в последующих релизах. [25]
Информация, однажды помещённая в хранилище Subversion, остаётся там навсегда: файл можно удалить в текущей ревизии, но всегда есть возможность получить из хранилища одну из предыдущих ревизий, в которых файл существовал. Хотя сохранность прошлых ревизий и является, собственно, целью использования систем управления версиями, иногда бывает необходимо полностью удалить из хранилища информацию, попавшую туда по ошибке. В Subversion не предусмотрено для этого никакого штатного способа [26] ; единственная возможность заключается в создании дампа хранилища, его редактировании (это текстовый файл) и последующем восстановлении хранилища из дампа. Существуют сторонние программы для автоматизации этого процесса, но, в любом случае, для выполнения этой операции требуется временное прекращение доступа к хранилищу и вмешательство администратора с привилегиями, достаточно высокими для того, чтобы полностью стереть старое хранилище и заменить его новым.