Установка и настройка 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.
Collabnet subversion client что это
We provide our global customers with solutions focused on enabling them to conceive, build and deliver the highest quality software at speed, in the manner and using the methods that best suit their particular requirements.
Optimize DevOps performance by measuring and automating it
Improve global team productivity on the most secure ALM platform
Secure, trace, and scale software development with enterprise-scale git
Expand agile across multiple teams
Integrate the entire software delivery value stream
Connect your ALM tools and make it easier to see, monitor, and trace workflows
Our solutions energize digital transformations. Our customers span industries including government, financial, and biotech. We inspire the future by enabling embedded and IoT technologies. We even make software development connect closely to the enterprise with value stream management. Our solutions free organizations to focus on their business challenges.
Interested in learning about agile or seeking Scrum or SAFe certification? Want to learn how to leverage our products from industry leaders in agile? From fundamentals to mastery, our experts will teach you what you need to know to apply your new knowledge successfully in your role.
Our knowledge and expertise spans methodologies, practices, and products. We’ve helped thousands of teams globally across various industries. What we have learned can save you time, reduce risk, and help you reach your goals. Put our knowledge to use for short-term expertise, support, or longer-term planning and execution.
CollabNet VersionOne’s Support is built on an unrelenting focus and commitment to Customer Success that results in consistently high customer satisfaction rating and high loyalty.
Apache ™ Subversion ® & Subversion Edge Support
CollabNet VersionOne founded the open source Subversion project more than 10 years ago, and continues to work on improving its capabilities and performance. As part of our product offering, CollabNet VersionOne provides various levels of support —from our community forums to Platinum 24X7 support. Choose a package that’s right for you. We have offerings for users that range from small business to enterprise. We offer Service Level Agreements, Phone Support, and easy access to Subversion Experts. The following chart details levels of coverage offerings can easily be customized to fit any specific
business need.
Paid Support
CollabNet VersionOne three support programs for Subversion: Silver, Gold, and Platinum on an annual or multi-year subscription basis.
Community Support
CollabNet VersionOne offers and hosts free support for Subversion, including Community forums where people discuss technical questions and best practices.
Why Choose CollabNet VersionOne for Subversion Support
Subversion Founder
Nobody knows more about Subversion than CollabNet VersionOne. We founded the open source project more than 10 years ago, and we continue to demonstrate our commitment to the application and the user community. Project Leaders of Subclipse, AnkhSVN projects are part of our Core Engineering Team. CollabNet VersionOne offers certified binaries, and now with Subversion Edge, we offer a certified stack that includes Apache and ViewVC. We’ve simplified Subversion installation and configuration. We have the largest active group of Subversion committers on staff.
SVN Committers in our Engineering team for support
Our support team lives and breathes Subversion. We work with the application every day, and we listen to what users have to say. Our commits are meant to continuously improve the code, and allow efficiencies for all users. If you have an issue or bug, there is no resource better qualified to solve it than a CollabNet VersionOne engineer.
Dedicated Subversion Support Team
As part of our service offering, we make available a dedicated support team. In addition, you can purchase our Dedicated Support Advisor service, whereby you receive a dedicated resource to manage all your support issues to resolution.
Global Coverage
No matter where you are, we have a team ready and available to assist you. CollabNet VersionOne has a global presence, with teams in the United States, Europe, China, Japan, Korea, and India.
Certified Subversion Binaries
CollabNet VersionOne recently announced the availability of Subversion Edge, a certified stack that includes Apache and ViewVC. We’ve simplified Subversion installation and configuration by adding an intuitive web user interface.
All Clients Supported [Subclipse, TortoiseSVN and AnkhSVN]
CollabNet Subversion works with any environment, with any third party tool you choose to use. We support all clients, and you can rest assured that your support engineer will be familiar with all components of your system.
P1 – Point Contact Assigned Until Issue Is Resolved
You will find our SLAs to be aggressive. For any P1 issue, you will be assigned a point of contact to facilitate communication until the issues is resolved to your satisfaction.
System Configuration Check
As an optional service, you can request a system configuration check & get our expert advice on recommended hardware.
Community Resources
Some of our best resources exist in the knowledge base that our community is known and respected for. Have a question, want some advice, need online training? Check out our user forums and see what the community has to offer.
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.
Subversion
Subversion [1] (также известная как «SVN» [2] ) — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.
В настоящее время Subversion используется многими сообществами разработчиков открытого программного обеспечения (в том числе сообществами, ранее использовавшими CVS). В их числе такие известные проекты, как Apache, GCC, Free Pascal, Python, Ruby, FreeBSD, AROS, Blender, Boost, Tor, OGRE. Subversion также широко используется в закрытых проектах и корпоративной сфере. Хостинг Subversion, в том числе для проектов с открытым кодом, также предоставляют популярные хостинг-проекты SourceForge.net, Tigris.org, Google Code и BountySource.
В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)». [8]
В качестве официальной документации позиционируется [11] книга издательства O’Reilly Media, выложенная в свободный доступ на сайте http://svnbook.red-bean.com/ и дописываемая авторами по мере выхода новых версий SVN. Там же публикуются её переводы на ряд языков, в том числе русский, но при том, что англоязычные версии книги сейчас описывают версии 1.6 и 1.5, на русском языке имеются лишь книги, описывающие версии до 1.4 включительно.
Содержание
История
Разработка Subversion была начата в 2000 году по инициативе и при финансовой поддержке CollabNet Inc. Инициаторы проекта хотели создать свободную систему управления версиями, в основном похожую на CVS, но лишённую её ошибок и неудобств. В то время не существовало лучших программ этого класса со свободной лицензией, CVS была стандартом де-факто среди разработчиков свободного программного обеспечения. Выбрав её за основу, разработчики Subversion надеялись упростить разработку за счёт использования уже проверенных концепций и в то же время облегчить переход на новую систему многочисленным пользователям CVS. [12]
Основные события истории развития Subversion.
Общие сведения
Возможности
Модель работы
Subversion — централизованная система (в отличие от распределённых систем, таких как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.
Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. Для совместной работы над файлами в Subversion преимущественно используется модель копирование — изменение — слияние. Кроме того, для файлов, не допускающих слияние (различные бинарные форматы файлов), можно использовать модель блокирование — изменение — разблокирование.
При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных.
При использовании доступа с помощью WebDAV также поддерживается прозрачное управление версиями — если любой клиент WebDAV открывает для записи и затем сохраняет файл, хранящийся на сетевом ресурсе, то автоматически создаётся новая версия.
Типы репозиториев
Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации [26] (Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок), каждая из них обладает своими преимуществами и недостатками. Считается, что FSFS легче правильно настроить, она требует меньшего внимания от администратора. Кроме того, до релиза 1.4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном (англ. wedged ) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1.2 для новых хранилищ по умолчанию используется FSFS.
Доступ к репозиторию
Subversion предоставляет следующие способы доступа к репозиторию:
Все эти способы могут быть использованы для работы с репозиториями обоих типов (FSFS и Berkeley DB). Для доступа к одному и тому же репозиторию могут одновременно использоваться разные способы.
Основные концепции
Файловая система
С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. Объекты в хранилище (файлы и директории) идентифицируются двумя «координатами»: именем и номером ревизии. Другими словами, хранилище представляет собой массив мгновенных снимков (ревизий) дерева файлов и директорий, индексируемый номером ревизии. Каждый такой снимок — обычная (одномерная) файловая система.
При необходимости указания на конкретную ревизию объекта используется запись вида: имя@ревизия, например, /main.c@29 — файл /main.c в ревизии 29. Такое указание ревизии, используемое для уточнения имени, называется стержневая ревизия (англ. peg revision ).
На рис. 1 показано графическое представление файловой системы: вертикальная ось соответствует множеству имён, горизонтальная — множеству ревизий.
Имена файлов
Имя объекта файловой системы в Subversion образуется по тем же правилам, что и в UNIX-подобных операционных системах: существует только одна корневая директория, элементы пути разделяются косой чертой («/»). Объектами файловой системы являются файлы и директории (а также символические ссылки, которые эмулируются из обычных файлов путём установки атрибута svn:special).
Номера ревизий
Номер ревизии в Subversion — это натуральное число (или 0 для самой первой ревизии), адресующее номер состояния хранилища в процессе изменения содержащихся в нём данных. Каждая успешная фиксация изменений порождает ровно одну новую ревизию в хранилище, то есть N-я ревизия — это состояние хранилища после N-й фиксации.
В Subversion ревизия характеризует состояние не отдельного файла, а всего хранилища в целом. Например, ревизия 32 (обведено пунктиром на рисунке) — это состояние трёх файлов и двух директорий, существовавших в хранилище на тот момент.
Номер ревизии является аналогом времени в том смысле, что меньшие номера ревизий соответствуют более ранним состояниям хранилища, а бо́льшие — поздним.
Номер ревизии можно рассматривать как некую временну́ю отметку в истории хранилища. Более того, с каждым номером ревизии связано абсолютное значение времени, когда эта ревизия была сделана (свойство svn:date). Однако указание номера ревизии удобнее, чем указание времени, так как нет путаницы с часовыми поясами, запись номера короче и номер ревизии не может быть изменён.
Оперативная и стержневая ревизии
Номер ревизии используется в двух различных контекстах:
Ревизия называется оперативной, если она указывается как ревизия или диапазон ревизий, к которому должна быть применена команда, например:
Однако указание только оперативной ревизии иногда может неоднозначно указывать на объекты хранилища. Например, в ситуации, показанной на рис. 2, возникает неоднозначность при выполнении следующей команды:
В команде указан диапазон оперативных ревизий ( 29:33 ), но области, выделенные на рисунке голубым и зелёным фоном, в равной степени можно считать историей файла /bar.txt в диапазоне ревизий 29:33. В подобных случаях необходимо указывать ещё и стержневую ревизию для разрешения неоднозначности. Стержневая ревизия — это номер ревизии, указанный в дополнение к URL объекта файловой системы (используется запись вида «URL@ревизия»). URL со стержневой ревизией всегда однозначно идентифицирует объект (файл или директорию). Команда применяется к той единственной цепочке состояний, которой принадлежит указанная пара URL@ревизия. В приведённом ниже примере первая команда выведет историю, выделенную на рисунке голубым фоном, а вторая — историю, выделенную зелёным фоном:
В качестве стержневой ревизии следует указывать как можно более позднее состояние интересующего объекта. Причина этого в том, что цепочка состояний однозначно отслеживается «назад», но не «вперёд». Например, URL со стержневой ревизией http://some.path/foo.txt@31 принадлежит двум цепочкам состояний (выделены соответственно зелёным и серым фоном). Из этих двух цепочек указанный URL адресует серую цепочку, то есть при движении «вперёд» от стержневой ревизии операции копирования игнорируются.
Операции над файловой системой
Над объектами файловой системы в хранилище Subversion могут быть произведены перечисленные ниже операции [27] (см. рис. 1). В скобках указано краткое именование операции в обозначениях команды svn status.
Фиксация изменений
Рабочая копия
Рабочая копия — это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая помимо собственно данных некоторую служебную информацию (скрытые директории с именем .svn). Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория (можно также извлечь директорию без поддиректорий, а потом докачивать их по мере необходимости). Другими словами, в Subversion рабочая копия всегда соответствует ровно одной директории хранилища. Извлечь из хранилища отдельный файл как рабочую копию невозможно.
Любая поддиректория рабочей копии Subversion 1.6 и более ранних версий также является полноценной рабочей копией, поскольку в каждой директории хранятся её служебные данные (каталоги .svn). Начиная с версии 1.7 в каждой рабочей копии присутствует только одна директория .svn в корне её каталога.
Рабочая копия является самодостаточной в том смысле, что Subversion не хранит каких-либо данных, относящихся к рабочей копии, вне её. Поэтому, имея одну рабочую копию, можно сделать ещё несколько копий простым копированием без затрат сетевого трафика.
В служебных директориях рабочей копии, помимо прочего, хранится так называемая чистая копия (англ. pristine copy ) — файлы рабочей копии в неизменённом виде, как они были извлечены из хранилища (для svn это ревизия с именем BASE). Наличие чистой копии позволяет быстро и без обращения к хранилищу выполнять операции просмотра и отката локальных изменений. Однако размер рабочей копии на диске примерно в два раза больше (данные + чистая копия данных), чем размер самих данных. Такой подход обусловлен тем, что дисковые ресурсы дешевле и доступнее, чем ресурсы сети передачи данных.
Как правило, создание рабочей копии является первым и необходимым этапом для фиксации локальных изменений, поскольку зафиксировать в хранилище можно только изменения, сделанные в рабочей копии. Исключением являются операции, которые могут быть выполнены прямо в хранилище без создания рабочей копии.
Транзакции
Работа с хранилищем в Subversion организована в форме транзакций со свойствами атомарности и изоляции из набора свойств ACID. Таким образом система управления версиями гарантирует целостность, непротиворечивость и доступность хранилища в любой момент времени.
NB: Данные свойства не гарантируются для рабочей копии Subversion — она, в отличие от хранилища, при сбое или прерывании может оказаться в промежуточном или заблокированном состоянии (то есть перед продолжением работы ее потребуется восстановить или пересоздать заново).
Локальные и удалённые формы команд
Все команды клиента Subversion можно разделить на следующие группы:
Структура хранилища
Структура проекта в хранилище
Формально Subversion не накладывает каких-либо ограничений на файловую структуру проекта — она может быть какой угодно в рамках правил именования объектов файловой системы. Тем не менее, существуют рекомендации, призванные облегчить работу с ветвями и метками. В простейшем случае в корневой директории хранилища рекомендуется создать как минимум три поддиректории:
где вся файловая структура проекта (основной линии разработки) должна содержаться в поддиректории trunk, поддиректория branches должна содержать ветви проекта, а tags — метки. Например, следующая структура директорий хранилища:
предполагает наличие у проекта (trunk) одной ветви «branch_1» и двух меток «tag_1» и «tag_2». Каждая из этих директорий (trunk, branch_1, tag_1 и tag_2) содержит копию соответствующей версии проекта.
Если (под)проектов в хранилище несколько, то такая структура поддиректорий создается для каждого (под)проекта:
то есть в корневой директории находятся директории проектов, и в каждом из них есть свои trunk, branches, tags, относящиеся только к этому проекту. Описанные структуры директорий хранилища являются лишь примерами, на практике хранилище можно организовать таким способом, который оптимально подходит в данном конкретном случае. [28] [29]
Другим способом хранения нескольких проектов является создание нескольких хранилищ. В разных хранилищах следует располагать проекты, которые никак не связаны между собой, поскольку между хранилищами нельзя будет выполнить операции копирования, перемещения и слияния. Несколько хранилищ можно при необходимости объединить в одно с сохранением истории ревизий (путём импорта командой svnadmin load с параметром --parent-dir).
Ветви
Subversion использует «файловую» модель (такую же, как и в Perforce [30] ) для реализации ветвей и меток, то есть ветвь является обычной директорией (можно также сделать ветвь из одного файла, а не директории). Новая ветвь создаётся командой 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 включает следующие этапы.
Ветвление
Ветвление является важным аспектом работы систем управления версиями, поскольку типичные приёмы [32] управления версиями (по крайней мере, при разработке программного обеспечения) подразумевают [источник не указан 318 дней] использование ветвей. 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
Преобразование репозитория
Существует программа cvs2svn, предназначенная для преобразования репозитория CVS в готовый репозиторий Subversion (либо в репозиторий git) или в текстовый дамп, который можно затем импортировать в репозиторий при помощи утилиты svnadmin. При этом cvs2svn сохраняет всю информацию, содержащуюся в репозитории CVS: ветви, метки, описания изменений, имена авторов, даты фиксации изменений. Кроме того, изменения в различных файлах, зафиксированные совместно, преобразуются в одну ревизию.
Отличия в использовании
Различия в работе с файлами
В CVS операции по перемещению (переименованию) и копированию файлов и директорий выполняются повторным добавлением объекта с новым именем и (при перемещении и переименовании) удалением старого объекта. При такой работе файлы и каталоги в хранилище создаются заново и теряют историю изменений. В Subversion для выполнения этих операций должны использоваться команды перемещения (move или mv) и копирования (copy). Их использование сохраняет историю изменений и позволяет избежать лишних операций (в особенности при операциях с директориями или даже ветками файловой системы).
В отличие от CVS, некоторые операции в рабочей копии (например, удаление и перемещение файла) Subversion выполняет самостоятельно. Описанные и другие отличия при работе с файлами рабочей копии просуммированы в следующей таблице (операция commit, там где она нужна в обоих случаях, опущена):
Адресация состояния хранилища
В Subversion для адресации состояния хранилища не обязательно создавать метки или использовать дату/время, в простых случаях (например, для получения версии после определенной фиксации) будет проще указать нужный номер ревизии.
Внутренняя структура
Уровни
Subversion спроектирован как набор библиотек, разделённых на несколько уровней. Каждый из них выполняет конкретную задачу и позволяет разработчикам создавать свои собственные инструменты, в зависимости от сложности и задачи.
Конфигурация клиента
Стандартная клиентская утилита Subversion — SVN, конфигурируется переменными окружения и INI-файлами, создаваемыми в домашнем каталоге пользователя в подкаталоге .subversion (расположение конфигурации в Windows-системах, в файлах или реестре, зависит от системных настроек). В конфигурации SVN также кеширует SSL-сертификаты, логины, пароли и т. п. (если это не запрещено в конфигурации) для доступа к серверам Subversion.
Cодержимое каталога .subversion:
Недостатки
Проблемы при переименовании файлов
Subversion не всегда может правильно обработать операции переименования файлов, если одновременно с переименованием изменяется и содержимое файла. Проблемы могут также возникнуть, если файл, переименованный в локальной копии, кто-то другой изменил в хранилище. Часть этих проблем исправлена в версии 1.5, однако это решение пока не полное. [38]
Слабая поддержка слияния ветвей
Невозможность удаления данных из хранилища
Информация, однажды помещённая в хранилище Subversion, остаётся там навсегда: файл можно удалить в текущей ревизии, но всегда есть возможность получить из хранилища одну из предыдущих ревизий, в которых файл существовал. Хотя сохранность прошлых ревизий и является, собственно, целью использования систем управления версиями, иногда бывает необходимо полностью удалить из хранилища информацию, попавшую туда по ошибке. В Subversion не предусмотрено для этого никакого штатного способа [41] ; единственная возможность заключается в создании дампа хранилища, его редактировании (это текстовый файл) и последующем восстановлении хранилища из дампа. Существуют сторонние программы для автоматизации этого процесса, но, в любом случае, для выполнения этой операции требуется временное прекращение доступа к хранилищу и вмешательство администратора с привилегиями, достаточно высокими для того, чтобы полностью стереть старое хранилище и заменить его новым.
засоряет файловую структуру проекта. Начиная с версии 1.7 в корне рабочей копии проекта создаётся одна директория «.svn», мета-данные в которой сохраняются с использованием SQLite.
