Оновлення робочої копії

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

Модифікація проекту Розробник модифікує проект, змінюючи вхідні в нього файли в робочій копії відповідно до проектним завданням. Ця робота проводиться локально і не вимагає звернень до сервера VCS.

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

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

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

- Оновлення робочої копії (зміни, зроблені в основної версії, зливаються з локальними).

- Фіксація змін (локальні зміни зливаються із змінами, вже зафіксованими в основної версії).

- Злиття гілок (зміни, зроблені в одній гілці розробки, зливаються із змінами, зробленими в інший).

- У всіх випадках ситуація принципово однакова і має такі характерні риси:

- Раніше була зроблена копія дерева файлів і каталогів репозиторія або його частини.

- Згодом і в оригінальне дерево, і в копію були незалежно внесені деякі зміни.

- Потрібно об'єднати зміни в оригіналі та копії таким чином, щоб не порушити логічну зв'язність проекту і не втратити дані.

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

1. Зміни можуть складатися в модифікації вмісту файлу, створення нового файлу або каталогу, видаленні чи перейменування раніше існуючого файлу або каталогу в проекті.

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

3. Створення, видалення та перейменування файлів в каталогах проекту можуть бути об'єднані автоматично, якщо тільки вони не конфліктують між собою.

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

1. Видалення і зміна одного і того ж файлу або каталогу.

2. Видалення і перейменування одного і того ж файлу або каталогу (у випадку, якщо система підтримує операцію перейменування).

3. Створення в різних версіях файлу з одним і тим же ім'ям і різним вмістом.

4. Зміни в межах одного текстового файлу, зроблені в різних версіях, можуть бути об'єднані, якщо вони знаходяться в різних місцях цього файлу і не перетинаються. В цьому випадку в об'єднану версію вносяться всі зроблені зміни.

5. Зміни в межах одного файлу, якщо він не є текстовим, завжди є конфліктуючими і не можуть бути об'єднані автоматично.

У всіх випадках базовою версією для злиття є версія, в якій було вироблено поділ версій, що зливаються.

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

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

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

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

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

<== попередня сторінка	\|	наступна сторінка ==>
Типовий порядок роботи з системою	\|	Конфлікти та їх вирішення

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

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