Як правильно працювати з svn, блог про веб програмуванні

Мета написання даного документа - розглянути кілька можливий стратегій застосування svn при створенні сховища web-проекту. Репозиторій повинен задовольняти основній вимозі - в стабільну версію проекту не повинні потрапляти дестабілізуючі зміни. Варіант, коли репозиторій наспіл просто як сховище файлів, не розглядаємо через його явної простоти. Більш того, він не відповідає основній вимозі, висунутій до сховища.
Якщо у вас є зауваження або пропозиції щодо цього документу Ви можете написати їх у коментарях.

Стартегия 1

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

структура сховища

Директорія / 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

структура сховища

Угоди про релізах

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

Цифра 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.

приклад 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 або для невеликих команд розробки.