- •Лабораторная работа№4 «Система версионного контроля Subversion»
- •1. Фундаментальные понятия
- •1.1 Хранилище
- •1.2 Модели версионирования
- •1.2.1 Проблема разделения файлов
- •1.2.2 Модель Блокирование-Изменение-Разблокирование
- •1.2.3 Модель Копирование-Изменение-Слияние
- •1.3 Subversion в действии
- •1.3.1 Url хранилища в Subversion
- •1.3.2 Рабочие копии
- •1.3.3 Url хранилища
- •1.3.4 Правки
- •1.3.5 Как рабочие копии отслеживают хранилище
- •1.3.6 Смешивание правок в рабочих копиях
- •1.3.7 Обновления и фиксации отделены друг от друга
- •1.3.8 Смешивание правок
- •2. Импорт
- •2.1 Путешествие во времени вместе с Subversion
- •2.2 Создание рабочей копии
- •2.3 Простейший рабочий цикл
- •2.4 Обновление рабочей копии
- •2.5 Внесение изменений в рабочую копию
- •2.6 Анализ изменений
- •2.6.1 Svn status
- •2.6.3 Svn diff
- •2.6.4 Svn revert
- •2.7 Разрешение конфликтов (при слиянии с чужими изменениями)
- •2.8 Слияние конфликтов вручную
- •2.9 Копирование файла поверх вашего рабочего файла
- •2.10 Использование svn revert
- •2.11 Фиксация изменений
- •2.12 Анализ истории
- •Svn log
- •Svn diff
- •Анализ локальных изменений
- •Сравнение рабочей копии с хранилищем
- •Сравнение хранилища с хранилищем
- •Svn cat
- •Svn list
- •Заключительное слово об истории
- •3. Ветвление и слияние
- •3.1 Что такое ветка?
- •3.2 Использование веток
- •3.3 Создание ветки
- •3.4 Работа с веткой
- •3.5 Ключевые идеи, стоящие за ветками
- •3.6 Копирование изменений между ветками
- •3.7 Копирование отдельных изменений
- •3.8 Ключевые идеи, стоящие за слиянием
- •3.9 Как правильнее всего использовать слияние
- •3.9.1 Ручной контроль слияния
- •3.9.2 Предварительный просмотр результатов слияния
- •3.9.3 Конфликты при слиянии
- •3.9.4 Учитывать или игнорировать происхождение
- •3.10 Типовые примеры
- •3.10.1 Полное объединение двух веток
- •3.10.2 Отмена изменений
- •3.10.3 Восстановление удаленных элементов
- •3.11 Типовые приемы использования веток
- •3.11.1 Ветки релизов
- •3.11.2 Функциональные ветки
- •3.11.3 Переключение рабочей копии
- •3.12 Метки
- •3.12.1 Создание простой метки
- •3.12.2 Создание комплексной метки
- •3.13 Поддержка веток
- •3.13.1 Структура хранилища
- •3.13.2 Продолжительность жизни информации
3.11 Типовые приемы использования веток
Управление версиями чаще всего используется при разработке программного обеспечения, поэтому здесь мы вкратце рассмотрим два наиболее часто используемых командами программистов приема ветвления/слияния. Если вы не используете Subversion для разработки программного обеспечения, можете пропустить этот раздел. Если вы — разработчик программного обеспечения, впервые использующий контроль версий, уделите этому разделу пристальное внимание, поскольку опытные разработчики считают использование данных приемов хорошим стилем. Такие приемы не являются специфичными для Subversion; они применимы к любой системе управления версиями. Однако, здесь мы взглянем на них с позиций Subversion.
3.11.1 Ветки релизов
Большинство программного обеспечения имеет типовой жизненный цикл: написание кода, тестирование, выпуск, повторный цикл. При таком подходе возникают две проблемы. Во-первых, разработчикам необходимо продолжать расширять функциональность в то время, как группа проверки качества будет заниматься тестированием предположительно стабильных версий программы. Во время тестирования не должна останавливаться разработка. Во-вторых, как правило, требуется поддерживать старые, уже выпущенные версии программы; если найдена ошибка в последней версии кода, то скорее всего она присутствует и в уже выпущенных версиях, поэтому пользователи захотят, чтобы эта ошибка была исправлена не дожидаясь выхода новой версии программы.
Здесь-то и может помочь контроль версий. Типичная процедура выглядит примерно так:
Разработчики фиксируют все новое в главную линию разработки. Каждодневные изменения фиксируются в /trunk: новая функциональность, исправление ошибок и тому подобное.
Главная линия разработки копируется в ветку «релиза». Когда команда разработчиков решает, что программа готова к выпуску (скажем, к релизу 1.0), тогда /trunk копируется, например, в /branches/1.0.
Группы продолжают работать параллельно. Одна группа начинает всестороннее тестирование ветки релиза, в то время как вторая группа продолжает работу (скажем, над версией 2.0) в /trunk. Если находятся ошибки в какой-либо из версий, исправления портируются по необходимости в одну или другую сторону. В какой-то момент этот процесс останавливается. Ветка «замораживается» для окончательной проверки перед релизом.
На основе ветки создается метка и выпускается релиз. Когда тестирование завершено, /branches/1.0 копируется в /tags/1.0.0 как справочный снимок. Метка запаковывается и отправляется пользователям.
Ветка продолжает поддерживаться. По мере продвижения работы над /trunk для версии 2.0, исправления ошибок продолжают портироваться из /trunkв /branches/1.0. Когда будет накоплено определенной количество исправлений, руководство может решить сделать релиз 1.0.1: /branches/1.0 копируется в/tags/1.0.1, метка пакуется и выпускается.
По мере развития программы эти этапы повторяются: когда работа над 2.0 будет завершена, создается новая ветка релиза 2.0, тестируется, создается метка и в последствии выпускается релиз. После нескольких лет в хранилище будет находиться определенное количество веток релизов, находящихся в режиме«сопровождения» и определенное количество меток, отражающих последние выпущенные ветки.