Как правильно работать с SVN

Цель написания данного документа — рассмотреть несколько возможный стратегий применения svn при создании репозитория web-проекта. Репозиторий должен удовлетворять основному требованию — в стабильную версию проекта не должны попадать дестабилизирующие изменения. Вариант, когда репозиторий испольуется просто как хранилище файлов, не рассматриваем из-за его явной простоты. Более того, он не соответствует основному требованию, предъявляемому к репозиторию.
Если у вас есть замечания или предложения по этому документу Вы можете написать их в коментариях.

Стартегия 1

Описание

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

Структура репозитория
/
    /
    /tags/
        /0.0.1
        /0.0.2
        ...
    /branches/
        /0.0.1
        /0.0.2
        ...

Директория /trunk — основная ветка разработки проекта. В нее вносятся все изменения и исправления ошибок.
Директория /tags содержит релизы проекта. Именно из поддиректорий директории /tags исходный код выкладывается на рабочие сервера.
Директория /branches необходима для упрощения внесения больших изменений в код проекта. В ней хранятся ветви разработки. Если человек разрабатывает большую фичу, то он должен создать себе бранч и время от времени синхронизировать его с trunk. По окончании разработки фичи этот бранч сливается с транком и удаляется.

Итак, /trunk — основная ветвь разработки системы. Релизы создаются на основе содержимого директории /trunk. Создавать релизы на основе бранчей в данном случае не рекомендуется.

Соглашение о релизах и ветвях разработки

Номер релиза состоит из трех цифр, разделенных точкой. Для удобства описания обозначим его как X.Y.Z.

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

Цифра Y отвечает за добавление новых фич и исправление ошибок, то есть номер Y увеличиваем при добавлении новых возможностей, заметных на уровне конечного пользователя. Поясню на счет исправления ошибок — на первый взгляд может показаться, что за исправление ошибок должен отвечать номер Z, но это не так. Например, в релизе 1.2.3 исправили несколько ошибок, залили их в /trunk. А через некоторое время выпустили новую версию 1.3.0 с фичами и этими исправлениями ошибок, т.е. багфиксы «автоматом» слились в Y при создании нового релиза из /trunk.

Z — исправление ошибок, внесение незначительных исправлений (например, небольшие изменения дизайна).

Примеры

Пример 1
Текущий релиз: 1.2.4.
Задание: Необходимо исправить ряд небольших ошибок, замеченных с момента релиза.
Действия: Вносим изменения в /trunk. Создаем стабилизирующий релиз /tags/1.2.5/. Выкладываем.

Пример 2
Текущий релиз: 1.2.4
Задание: Необходимо разработать дополнительную фичу, выполнение задания займет от нескольких дней до нескольких недель.
Действия: Создаем бранч /branches/1.3.0/. Работаем в бранче. Несколько раз в неделю синхронизируемся с /trunk для поддержания актуальности бранча и упрощения последующего слияния бранча с транком. По окончании разработки бранч синхронизируется с транк. Тестируется. Если все в порядке, то изменения заливаются в транк. Бранч удаляется. На основе транка делается релиз /tags/1.3.0/.

Пример 3
Текущий релиз: 1.2.4
Задание: Необходимо разработать несколько (пусть две) дополнительных фич, выполнение задания займет от нескольких дней до нескольких недель.
Действия: Создаем бранчи /branches/1.3.0 и /branches/1.3.1. Работаем независимо в разных бранчах. Несколько раз в неделю бранчи синхронизируются с trunk для поддержания актуальности бранчей и упрощения последующего слияния бранчей с транком. По окончании разработки бранчи по очереди синхронизируется с транком. Результат тестируется. Если все в порядке, то изменения заливаются в /trunk. Бранчи удаляются. На основе транка делается релиз /tags/1.3.0/.

Стартегия 2

Описание

Это классическая стратегия, рекомендуемая в документации по svn. Применения этой стратегии будет гарантировать, что в репозиторий будет удовлетворять требованию, что в стабильную версию проекта не попадают дестабилизирующие изменения. Эта глава всего лишь свободный пересказ одной из глав руководства по svn.

Структура репозитория
/
    /trunk
    /tags/
        /0.1.0
        /0.1.1
        ...
    /branches/
        /0.1-stable
        /0.2.0
        /0.2.1
        ...

Директория /trunk — основная ветка разработки проекта. В нее вносятся все изменения и исправления ошибок.
Директория /tags содержит релизы проекта. Именно из поддиректорий директории /tags исходный код выкладывается на рабочие сервера.
Директория /branches необходима для упрощения внесения больших изменений в код проекта, а также для внесения исправлений в текущий релиз проекта.

Соглашения о релизах

Номер релиза состоит из трех цифр, разделенных точкой. Для удобства описания обозначим его как X.Y.Z.

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

Цифра Y отвечает за добавление новых фич и исправление ошибок, то есть номер Y увеличиваем при добавлении новых возможностей, заметных на уровне конечного пользователя. Поясню на счет исправления ошибок — на первый взгляд может показаться, что за исправление ошибок должен отвечать номер Z, но это не так. Например, в релизе 1.2.3 (на самом деле изменения вносятся в бранч /branches/1.2-stable) исправили несколько ошибок, залили их в /trunk. А через некоторое время выпустили новую версию 1.3.0 с фичами и этими исправлениями ошибок, т.е. багфиксы «автоматом» слились в Y при создании нового релиза из /trunk.

Z — исправление ошибок, внесение незначительных исправлений (например, небольшие изменения дизайна).

Соглашения о ветвях разработки

Ветви разработки могут быть двух типов в зависимости от назначения ветви.
Первый вариант — ветви для существенных изменений (номера вида 0.1.0, 0.2.0 и т.д.). Если человек разрабатывает большую фичу, то он должен создать себе бранч и время от времени синхронизировать его с /trunk. По окончании разработки фичи этот бранч сливается с /trunk и удаляется. Далее будем называть такие ветви временными.
Если ветвь временная, то ее название будет состоять из трех цифр — X.Y.Z. Номер Y должен быть на единицу больше номера текущего релиза. То есть если текущий релиз имеет версию 1.2.4, то создавать ветвь необходимо с номером 1.3.0.

Второй вариант — ветви, соответствующие релизам, выкладываемым на рабочие сервера (номера вида 0.1-stable, 0.2-stable). Эти ветви необходимы для исправления ошибок в текущем релизе. На основе этих ветвей создаются стабилизационные релизы. Это ветви релиза. Номера ветвей релиза имеют другую структуру — X.Y-stable.

Примеры

Пример 1
Исходные данные: исходники в /trunk.
Задание: Необходимо создать первый релиз и выложить код на рабочие сервера.
Действия:
Создаем бранч для поддержки (см. пример 2) релиза (svn copy /trunk /branches/1.0-stable)
Создаем первый релиз (svn copy /branches/1.0-stable /tags/1.0.0)

Пример 2
Исходные данные: В релизе 1.0.0 из примера 1 обнаружен ошибка.
Задание: Необходимо исправить ошибку.
Действия:
Исправляем ошибку в /branches/1.0-stable
Портируем изменения в /trunk
Создаем стабилизационный релиз /tags/1.0.1 (svn copy /branches/1.0-stable /tags/1.0.1)
Переключаем сервер на новый релиз командой svn switch.

Пример 3
Исходные данные: текущий релиз 1.0.1.
Задание: разработать новую фичу для проекта, вермя выполнения около недели.
Действия:
Создаем бранч /branches/1.2.0
Все изменения относительно новой фичи вносятся в эту ветвь.
Ветвь систематически синхронизируется с /trunk для поддержания актуальности ветви.
По окончании работ над фичей ветвь сливается с /trunk.
/trunk тестируется.
Если все в порядке, то бранч /branches/1.2.0 удаляется.
На основе /trunk создается новые релиз /tags/1.2.0
На основе /tags/1.2.0 создается бранч релиза /branches/1.2-stable
/tags/1.2.0 выкладывается на рабочие сервера

Замечания

/trunk — основная ветвь разработки системы.
Релизы создаются на основе ветвей /branches/x.x-stable.
Следует отметить, что при выходе релиза 1.2.0 отпадает необходимость в поддержке бранча /branches/0.1-stable. Эту ветвь можно удалить.

Выводы

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

  • prefeelin

    Отлично я нашла что искала

    :)

  • php blog

    SVN полезная штука

  • Слава

    Вопрос по примеру №2

    > Действия:

    > Исправляем ошибку в /branches/1.0-stable

    > Портируем изменения в /trunk

    Каким образом происходит портирование?

    нсколько я понимаю merge --reintegrate сделать не получится. т.к. возможно потребуется исправлять другие ошибки а после reintegrate этого сделать не получится. Если я правильно понимаю.

Запись навигация

Top