МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
ОСНОВИ РОБОТИ З СИСТЕМАМИ КОНТРОЛЮ ВЕРСІЙ
МЕТОДИЧНІ ВКАЗІВКИ
до лабораторної роботи № 1
з курсу: “Технології комп’ютерного проектування”
Для студентів базового напрямку
6.050101 “Комп’ютерні науки”
Львів – 2012
1. Мета роботи
Мета роботи – ознайомитись з системами контролю версій з централізованим репозиторієм на прикладі клієнтської частини системи контролю версій Turtoise SVN.
2. Теоретичні відомості
Системи конролю версій (СКВ) використовують в процесі розробки програмного забезпечення для відстеження, документування та контролю над поступовими змінами в електронних документах: у прогрмному коді, кресленнях, електронних моделях та інших документах, над якими одночасно працюють декілька людей. Системи контролю версій забезпечують можливість групі розробників працювати над спільним проектом, відстежуючи зміни проекту та синхронізуючи їх між розробиками. Сучасні СКВ дають змогу відслідковувати зміни, зберігати історію змін, створювати контрольні точки (таги), розгалуження проектів (гілки), а також забезпечують можливисть повернення до будь-якої з попередніх версій окремого електронного документу чи проетку в цілому.
Невід’ємною частиною системи контролю версій є репозиторій - сховище даних, де зберігаються файли проекту та історія їх змін. В залежності від способу розміщення репозирію розрізняють два типип СКВ:
системи з централізованим репозиторієм. Як правило такі системи побудовані на архітектурі клієнт-сервер. Репозиторій проекту знаходиться на серверній стороні, а кожен з клієнтів використовує свою копію центрального репозиторію для роботи з проектом та внесення в нього змін. Сервер забезпечує можливість синхронізації даних між клієнтом та сервером. Таким чином зміни з локальної копії репозиторію можуть бути внесені до основного репозиторію, а звідти розповсюджені на інші клієнтські копії.
системи з розподіленими репозиторіями (Distributed Version Control System, DVCS). В таких СКВ не існує централізованого репозиторію, натомість кожен розробник працює зі своєю версію репозиторію. Проте часто виділяють так звану основну гілку – репозиторій який використовується всіма розробниками для синхронізації своїх змін. Кожен розробник в будь-який момент часу має змогу синхронізувати свій репозиторій з основною гілкою і навпаки.
В даній лаборатоній роботі розглянуто особливості роботи з клієнтською частиною централізованої системи контролю версій TortoiseSVN. Дана система контролю версій має зручний інтерфейс користувача. Отримати доступ до основних команд клієнта TurtoiseSVN можна через контекстне меню будь якого файлу чи папки в ОС Windows. Рис.1
Рис.1 Інтеграція команд Turtoise SVN в контекстне меню ОС Windows
Для початку роботи з системою контролю версій необхідно або обрати існуючий, або створити новий репозиторій. Створити новий репозиторій можна за допомогою пункту контекстного меню TurtoiseSVN->Create repository here. Якщо, центральний репозиторій вже створено необхідно створити на власному ПК локальну копію, для цього необхідно в контекстному меню директорії в якій необхідно створити локальну копію репозиторію виконати команду SVN Checkout… (рис.2), після чого у вікні, яке з’явиться ввести URL адресу репозиотрію, нариклад https://tortoisesvn.googlecode.com/svn/trunk. (Рис. 3) (URL репозиторію який необхідно використати в даній Лабораторній роботі слід отримати у викладача). Локальну копію репозиторію можна створити як у існуючій папці так і створивши нову папку і виконавши в її контекстному меню команду ‘SVN Checkout…’
Рис.2 Команда SVN Checkout…
Рис.3 Вікно створення локальної копії репозиторію
Після натиснення на кнопку ОК, система скопіює вміст центрального репозиторію у вказану директорію на локальному жорсткому диску. Якщо доступ до центрального репозиторію захищений паролем, то після натиснення на кнопку ОК з'явиться вікно вводу логіну і паролю (Рис.4), куди необхідно ввести дані користувача (пароль доступу до центрального репозиторію кожен студент отримає на свою адресу електронної пошти, адресу слід повідомити викладачу).
Рис. 4 Вікно вводу особистих даних користувача (логін і пароль)
Як правило, кожен репозиторій має наступну структуру:
папка репозиторію/trunk
папка репозиторію /branches
папка репозиторію /tags
Папка trunk містить файлову структу основної гілки репозиторію. Дану гілку прийнято вважати останньою версією програмного забезпечення. Вона завжди повинна підтримуватись в робочому стані.
Папка branches зберігає всі існуючі розгалуження проекту. Суть і доцільність створення розгалужень найкраще розглянути на прикладі. Уявімо собі ситуацію, коли програмний продукт вже використовується замовником, проте команда розробників продовжує вдосконалювати його і розробляти новий функціонал. Згідно угоди між замовником і розробниками, нова версія ПЗ має постачатись замовнику щотижня. Що робити коли розробка певного функціоналу триватиме більше ніж тиждень? Для цього можна використати розгалуження, суть якого полягає у створенні гілки (копії поточного стану центрального репозиторію), в якій і буде проводитись розробка довготривалого функціоналу. Всі інші зміни, які можна виконати протягом одного тижня і віддати замовнику, будуть здійснюватись в центральному репозиторії. Після того, як робота з суміжній гілці буде завершена, можна буде здійснити синхронізацію цієї гілки з центральним репозиторієм. В проекті може існувати кілька розгалужень одночасно; всі гілки прийнято зберігати у папці branches.
Папка tags. СКВ TurtoiseSVN дає можливість створювати контрольні точки проекту, так звані таги. Таг дозволяє зберегти поточний стан центрального репозиторію чи гілки. Таги прийнято використовувати для збереження станів проекту.
Для створення гілки чи тагу необхідно в контекстному меню локального репозиторію вибрати команду branch/tag (рис. 5). Для створення відгалуження від центральної гілки необхідно виконати команду ‘Branch/tag’ на папці trunk. Слід пам’ятати, що команда branch/tag створить гілку в тому місці ієрархії де вона була виконана. Наприклад якшо виконати команду в корені локальної копії репозиторію то в результаті ми створимо гілку усього локального репозиторію, тобто папок branch, tag i trunk.
Рис. 5 Команда Branch/tag в контекстному меню СКВ Turtoise SVN
У вікні створення гілки/тагу (Рис. 6) необхідно вказати номер ревізії з якої буде створено гілку/таг (термін HEAD revision означає останню, тобто поточну версію центрального репозиторію) та шлях до папки, де необхідно зберегти новостворену гілку/таг (таги зберігаємо в папці tags, а розгалуження в папці branches. Також необхідно вказати папку для тагу чи гілки, що створюється, наприклад tags/t1/ - для створення гату t1 чи branches/b1/ - для створення гілки b1). Для створення гілки з поточної версії центрального репозиторію необхідно зі списку опцій ‘Create copy in the repository from’: вибрати опцію ‘HEAD revision in the repository’. Прийнято гілки зберігати у папці branches а таги у папці tags. (Під час виконання лабораторної роботи папки brances і tags необхідно створити. На тому ж рівні де знаходиться папка trunk). При створенні гілки/тагу можна вказати коментар, який буде присвоєний даній гілці/тагу. Новостворена гілка чи таг буде створена в центральному репозиторії, локальну копію тагу чи гілки можна створити виконавши команду Update(наприклад Update -> branches чи tags)
Рис. 6 Створення гілки/тагу
Як правило, таги використовують для збереження версій коду в ключових точках життєвого циклу проекту, наприклад кожного разу, коли нова версія проекту відправляється замовнику. Гілки ж використовують для ведення паралельних розробок, які з тих чи інших причин не можуть вестись в центральному репозиторії. Логічним, проте не обов'язковим, кінцем життєвого циклу кожної гілки є процес внесення змін з цієї гілки в центральний репозиторій.
Після створення нової гілки можна виконати команду Update для папки branches в локальному репозиторії, після чого в папці branches з'явиться дирикторія, яку було вказано при створенні гілки. В цю директорію буде скопійовано відгалуження, яке було створене в центральному репозиторії. Далі роботу з відгалуженням можна здійснювати в цій директорії (локально).
Іншим способом є переключення основної гілки репозиторію на створену гілку. Це можна зробити виконавши команду switch на центральній гілці локальної копії репозиторію (папка trunk). В діалоговому вікні, що з’явиться, в полі ‘To path’ необхідно вказати адрес гілки, в яку необхідно переключити центральну гілку, наприклад /branches/b1. Після того, як операція Switch буде виконана, всі операції Commit, які дубуть здійснюватись над директорією trunk, вноситимуть зміни не у основну гілку репозиторію, а у гілку, на яку було здійснено переключення (в наведеному прикладі на гілку b1).
Для внесення змін з відгалуження в основну гілку необхідно виконати команду ‘Merge’ на основній гілці (директорія trunk при умові, що ця директорія в даний момент є основною гілкою) і виконати такі кроки:
У діалоговому вікні, що з’явиться, зі списку опцій ‘Merge Type’ слід вибрати опцію Reintegrate a Branch і перейти до наступного діалогового вікна натиснувши кнопку ‘Next’.
Вказати шлях до гілки, з якою необхідно виконати злиття, натиснути кнопку 'Next'.
Натиснути кнопку ‘Merge’.
Н
а
рис. 7 зображено можливий шлях розвитку
проекту, створення розгалужень, їх
синхронізація з основною гілкою та
створення тагів.
Рис. 7 Приклад створення розгалужень і тагів
Локальну копію репозиторію можна редагувати не вносячи змін в центральний репозиторій. Для синхронізації з центральним репозиторієм існує 2 команди (рис. 8):
Commit – відображає перелік відмінностей між локальним репозиторієм і центральним. Якщо в переліку змін немає конфліктів, користувач може синхронізувати локальний репозиторій з центральним і таким чином внести зміни в центральний репозиторій.
Update – оновлення локального репозиторію. Після виконання даної команди локальний репозиторій буде оновлено змінами в центральному з моменту останнього оновлення.
Рис.8 Команди Commit і Update в контекстному меню локального репозиторію
При виконанні будь-яких змін у центральному репозиторії (створення гілки/тагу, внесення змін, тощо...) у відповідному діалоговому вікні СКВ буде поле ‘Log message’, яке призначене для вводу коментаря про внесені зміни. Рекомендується ніколи не залишети це поле пустим.
СКВ буде позначати файли в локальній копії репозиторію відповідно до їх статусу. Наприклад файл який щойно додано, буде містити піктограму ‘+’, а файл, в який було внесено певні зміни і який відрізняється від оригіналу в центральному репозиторії, буде позначено символом ‘!’. Усі можливі пікторгами статусів файлів і папок зображено на рис. 9
Рис. 9 Піктограми статусів файлів і папок в СКВ TortoiseSVN
Для роботи з файлами в системі контролю версій використовують дві команди:
Add: використовується коли необхідно додати файл у репозиторій. Додати файл у репозиторій можна двома способами:
1) додати файл у локальну копію репозиторію і в контекстному меню доданого файлу вибрати команду Add (Рис. 10), після чого виконати команду Commit.
2) Додавши файл в локальний репозиторій виконати команду Commit і позначити даний файл як такий, що необхідно додати.
Рис. 10 Команда Add в контекстному меню доданого файлу.
Delete: щоб видалити файл з репозиторію необхідно:
викликати контекстне меню СКВ TurtoiseSVN, в якому вибрати опцію Delete (Рис.11). При цьому даний файл буде помічено як такий, що необхідно видалити і після виконання операції Commit він буде видалений з центрального репозиторію.
Рис. 11 Видалення файлу з центрального репозиторію за допомогою команди Delete
2) Видалити файл з локального репозиторію. Виконати команду Commit.
При виконанні команди Commit користувачу відкривається вікно зі списком відмінностей між локальним репозиторієм та центральним (Рис. 12). Є тири види відмінностей: видалення, додавання, модифікація. В цьому вікні користувач може відмітити папки і файли, зміни в яких необхідно внести в центральний репозиторій. Також в контекстному меню доступні функції перегляду і редагування відмінностей.
Рис. 12. Вибір змін, які будуть внесені в центральний репозиторій після виконання команди Commit
З моменту внесення файлу в центральний репозиторій, СКВ починає контролювати зміни в цьому файлі і записувати історію змін. Це дає можливість в будь-який момент повернутись до певної версії (ревізії) файлу, порівняти різні версії файлу, чи знайти відмінності між різними ревізіями.
В процесі оновлення локального репозиторію, СКВ в автоматизованому режимі спробує оновити локальну копію. Під час оновлення можуть бути виконані наступні операції:
Додавання/видалення файлу/папки
Переіменування файлу/папки
Зміна файлу
Під час виконання СКВ операції зміни файлу можуть виникнути конфліктні ситуації. Наприклад коли в центральному репозиторії відбулися зміни в тій самій частині файлу, що і в локальній копії. В такому випадку, коли СКВ не зможе однозначно і безпомилково сумістити зміни в центральному репозиторії і в локальній копії, виникне конфліктна ситуація відносно даного файлу. При виникненні конфліктної ситуації СКВ проінформує про неї користувача і заблокує можливість внесення файлу з конфліктами до центрального репозиторію до того часу поки в файлі не будуть вирішені всі конфлікти. Існує три способи вирішення конфліктних ситуацій у СКВ:
Використати для вирішення конфлікту версію файла з центрального репозиторію
Використати для вирішення конфлікту версію файла з локального репозиторію
Вирішити конфлікти самостійно. В цьому випадку СКВ надасть користувачу редактор, в якому будуть відображені версії конфліктного файла в центральному та локальному репозиторіях, а також результуючий файл з вирішеними конфліктами. В цьому редакторі користувач має змогу самостійно вирішити всі конфлікти (в кожному з конфліктних рядків файлу). Кожен з конфліктів, на які вкаже редактор, необхідно помітити як вирішений, після чого локальна версія файлу буде розблокована і її можна буде внести в центральний репозиторій. На рис.13 зображено редактор вирішення конфліктів в СКВ.