Розподілені системи управління версіями

Також відомі як англ. Distributed Version Control System, DVCS. Такі системи використовують розподілену модель замість традиційної клієнт-серверної. Вони, в загальному випадку, не потребують централізованому сховищі: вся історія зміни документів зберігається на кожному комп'ютері, в локальному сховищі, і при необхідності окремі фрагменти історії локального сховища синхронізуються з аналогічним сховищем на іншому комп'ютері. У деяких таких системах локальне сховище розташовується безпосередньо в каталогах робочої копії. Коли користувач такої системи виконує звичайні дії, такі як витяг певної версії документа, створення нової версії тощо, він працює зі своєю локальною копією сховища. У міру внесення змін, сховищ, що належать різним розробникам, починають різнитися, і виникає необхідність в їх синхронізації. Така синхронізація може здійснюватися за допомогою обміну патчами або так званими наборами змін (англ. Change sets) між користувачами. Описана модель логічно близька створенню окремої гілки для кожного розробника в класичній системі управління версіями (в деяких розподілених системах перед початком роботи з локальним сховищем потрібно створити нову гілку). Відмінність полягає в тому, що до моменту синхронізації інші розробники цієї гілки не бачать. Поки розробник змінює тільки свою гілку, його робота не впливає на інших учасників проекту і навпаки. По завершенні відокремленої частини роботи, внесені до гілки зміни зливають з основною (загальною) гілкою. Як при злитті гілок, так і при синхронізації різних сховищ можливі конфлікти версій. На цей випадок у всіх системах передбачені ті чи інші методи виявлення і вирішення конфліктів злиття.

З точки зору користувача розподілена система відрізняється необхідністю створювати локальний репозиторій і наявністю в мові двох додаткових команд: команди отримання репозиторія від віддаленого комп'ютера (pull) і передачі свого репозиторія на вилучений комп'ютер (push).

Перша команда виконує злиття змін віддаленого і локального репозиторіїв з приміщенням результату в локальний репозиторій; друга - навпаки, виконує злиття змін двох репозиторіїв з приміщенням результату в віддалений репозиторій.

Як правило, команди злиття в розподілених системах дозволяють вибрати, які набори змін передаватимуться в інший репозиторій або вилучатись з нього, виправляти конфлікти злиття безпосередньо в ході операції або після її невдалого завершення, повторювати або відновлювати незакінчена злиття. Зазвичай передача своїх змін до чужої репозиторій (push) завершується вдало тільки за умови відсутності конфліктів. Якщо конфлікти виникають, користувач повинен спочатку злити версії у своєму репозиторії (виконати pull), і лише потім передавати їх іншим.

Зазвичай рекомендується організовувати роботу з системою так, щоб користувачі завжди або переважно виконували злиття у себе в репозиторії. Тобто, на відміну від централізованих систем, де користувачі передають свої зміни на центральний сервер, коли вважають за потрібне, в розподілених системах більш природним є порядок, коли злиття версій ініціює той, кому потрібно отримати його результат (наприклад, розробник, керуючий складальним сервером).

Основні переваги розподілених систем - їх гнучкість і значно більша (порівняно з централізованими системами) автономія окремого робочого місця. Кожен комп'ютер розробника є, фактично, самостійним і повнофункціональним сервером, з таких комп'ютерів можна побудувати довільну за структурою та рівнем складності систему, задавши (як технічними, так і адміністративними заходами) бажаний порядок синхронізації. При цьому кожен розробник може вести роботу незалежно, так, як йому зручно, змінюючи і зберігаючи проміжні версії документів, користуючись усіма можливостями системи (у тому числі доступом до історії змін) навіть за відсутності мережевого з'єднання з сервером. Зв'язок з сервером або іншими розробниками вимагається виключно для проведення синхронізації, при цьому обмін наборами змін може здійснюватися за різними схемами.

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

Блокування файлу або групи файлів (для зберігання ознаки блокування потрібен загальнодоступний і постійно знаходиться в он-лайні центральний сервер). Це змушує застосовувати спеціальні адміністративні заходи, якщо доводиться працювати з бінарними файлами, непридатними для автоматичного злиття.

Стеження за певним файлом або групою файлів (зміни файлів відбуваються на різних серверах, злиття і виділення гілок відбуваються локально, про зміни стає відомо тільки при синхронізації, причому не всім розробникам, а тільки тим, хто в даній синхронізації бере).

Єдина наскрізна нумерація версій системи та / або файлів, в якій номер версії монотонно зростає (така нумерація також вимагає наявності головного сервера, що задає номера версій для всіх інших).

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

Можна виділити наступні типові ситуації, в яких використання розподіленої системи дає помітні переваги:

1. Періодична синхронізація декількох комп'ютерів під управлінням одного розробника (робочого комп'ютера, домашнього комп'ютера, ноутбука і так далі).

2. Використання розподіленої системи позбавляє від необхідності виділяти один з комп'ютерів в якості сервера, а синхронізація виконується за потребою, зазвичай при «пересадці» розробника з одного пристрою на інший.

3. Спільна робота над проектом невеликої територіально розподіленої групи розробників без виділення загальних ресурсів.

Як і в попередньому випадку, реалізується схема роботи без головного сервера, а актуальність репозиторіїв підтримується періодичними синхронізація за схемою «кожен з кожним».

Крупний розподілений проект, учасники якого можуть довгий час працювати кожен над своєю частиною, при цьому не мають постійного підключення до мережі. Такий проект може використовувати централізований сервер, з яким синхронізуються копії всіх його учасників. Можливі й більш складні варіанти - наприклад, із створенням груп для роботи за окремими напрямками всередині більшого проекту. При цьому можуть бути виділені окремі «групові» сервери для синхронізації роботи груп, тоді процес остаточного злиття зміни стає деревоподібним: спочатку окремі розробники синхронізують зміни на групових серверах, потім оновлені репозиторії груп синхронізуються з головним сервером. Можлива робота і без «групових» серверів, тоді розробники однієї групи синхронізують зміни між собою, після чого будь-який з них (наприклад, керівник групи) передає зміни на центральний сервер. У традиційній «офісної» розробці проектів, коли група розробників відносно невелика і цілком знаходиться на одній території, в межах єдиної локальної комп'ютерної мережі, з постійно доступними серверами, централізована система може виявитися кращим вибором через свою більш жорсткої структури і наявності функціональності, відсутньої в розподілених системах (наприклад, вже згаданої блокування). Можливість фіксувати зміни без їх злиття в центральну гілку в таких умовах легко реалізується шляхом виділення незавершених робіт в окремі гілки розробки.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Базові принципи розробки ПЗ в VCS	\|	Словник

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.