ЛАБОРАТОРНА РОБОТА № 12-13
ЦЕНТРАЛІЗОВАНА СИСТЕМА КЕРУВАННЯ ВЕРСІЯМИ SUBVERSION

 

Мета: набути навичок роботи з централізованою системою контролю версій Subversion.

 

Довідка

Для організації колективної роботи над програмним проектом розробниками, як правило, використовується певна система контролю версій. Призначення такої системи – дати змогу названому колективу здійснити за потреби повернення до певної попередньої версії проекту. Передумовами до цього можуть бути, зокрема, помилки, виявлені в результаті внесення змін до проекту.

Існує чимало різноманітних систем контролю версій. Найпоширеніші із них – Subversion (SVN) та Git. Названі системи є демонстраціями двох принципово різних підходів до здійснення контролю версій: SVN – централізованого, а Git – децентралізованого підходу [1]. Кожен із підходів має як переваги, так і недоліки. Git, наприклад, характеризується більшими (у порівнянні із SVN) витратами обчислювальних ресурсів (пам'яті), проте його децентралізованість сприяє стійкості до виходу із ладу окремих обчислювальних вузлів мережі із розміщеними на них версіями проекту, використовуваних колективом розробників.

Дана робота присвячена централізованій системі контролю версій SVN [2]. Централізованість полягає у виділенні окремого вузла – серверу, на якому розміщується репозитарій проекту. Проект при цьому розглядається як деревовидна структура, елементами якої є файли та каталоги. На клієнтських вузлах при цьому зберігаються копії (робочі копії) репозитарію.

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

Розробником SVN є компанія CollabNet. В даній роботі використовувалась версія Subversion 1.8.10. Актуальну версію можна завантажити за посиланням https://subversion.apache.org/.

Базові поняття SVN:

20

– репозитарій – центр збереження інформації, розміщений на сервері; контент репозитарію (файли, каталоги) представлений у вигляді деревовидної структури; репозитарій можна розглядати як різновид файлового сервера;

– робоча копія (РК) – копія репозитарію, розміщена на клієнтському вузлі. Робочу копію можна розглядати як локальне робоче середовище клієнта.

РК – дерево каталогів із набором файлів [3]. Кожна РК містить службовий каталог .svn, що містить дані про зміни в РК.

Архітектуру SVN, що ґрунтується на поняттях репозитарію та РК, наведено на рис. 2.1.

 

Рис. 2.1. Компоненти та утиліти SVN

 

Ключові утиліти SVN – svn, svnserve, svnadmin – представлено на рис. 2.1. Їх призначення роз’яснено в табл. 2.1. Користування наведеними утилітами можливе, наприклад, за рахунок інсталяції збірки CollabNetSubversion-client-1.7.8-1-Win32.

 

Таблиця 2.1 – Утиліти SVN

 

Утиліта svnserve – це спеціалізований сервер, що забезпечує доступ до репозитарію через протокол TCP/IP.

Взаємодія з репозитарієм можлива із використанням протоколів, наведених в табл. 2.2.

 

Таблиця 2.2 – Протоколи взаємодії з репозитарієм

 

При виконанні роботи будуть використовуватися протоколи file:/// та svn://.

Взаємодія з репозитарієм може здійснюватися згідно однієї з наступних моделей:

– блокування/модифікація/розблокування – одночасна взаємодія з репозитарієм декількох клієнтів (розробників) неможлива;

– копіювання/модифікація/злиття – на клієнтських вузлах створюються РК репозитарію; кожний із розробників працює із власною копією, якими потім модифікується репозитарій. Ця модель буде використовуватися в роботі.

Модель з блокуванням доречно використовувати при роботі із бінарними файлами (звукові, графічні), де неможливо об’єднувати конфліктні зміни [3].

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

У випадку використання протоколу svn:// (табл. 2.2) потрібно здійснювати запуск серверу svnserve – за допомогою однойменної утиліти. Правила взаємодії з репозитарієм при цьому регламентуються вмістом конфігураційного файлу svnserve.conf, розміщеного в каталозі conf репозитарію (лістинг 2.1).

 

//Лістинг 2.1. Вміст конфігураційного файлу репозитарію

[general]

anon-access = write

auth-access = write

password-db = passwd

realm = repository No1

 

Модифікація файлу svnserve.conf виконується шляхом зміни значень конфігураційних параметрів (табл. 2.3).

 

 

Таблиця 2.3 – Параметри конфігураційного файлу svnserve.conf

 

Типовий сценарій роботи з репозитарієм можна представити наступним чином:

- створення репозитарію – svnadmin create \path, де \path – шлях до каталогу, в якому планується розмістити репозитарій;

- імпортування структури файлів та каталогів до створеного репозитарію – svn import source destination –m mark, де source – шлях до кореневого каталогу деревовидної структури файлів та каталогів, призначених для імпорту, destination – шлях до каталогу з репозитарієм із зазначенням одного з протоколів, наведених в табл. 2.2, mark – рядок, що унікальним чином ідентифікує здійснювану операцію;

- перегляд вмісту репозитарію, використовуючи команду svn list або svnlook tree. У першому випадку вміст буде виведено у вигляді списку, у другому – у вигляді деревовидної структури. Шаблони використання названих команд наступні: svn list file:///path та svnlook tree \path, відповідно. Для команди svn list, на відміну від команди svnlook tree, слід вказувати абсолютний шлях до репозитарію;

- опціональний запуск серверу svnserve, що дасть змогу надалі користуватися спеціалізованим протоколом доступу svn://. Формат відповідної команди наступний: svnserve –d –r \path;

- створення РК репозитарію, що дасть змогу організувати взаємодію з останнім згідно моделі копіювання/модифікація/злиття. Для цього використовується команда svn checkout або команда svn co. Наприклад, наступним чином можна створити РК, яка міститиметься у каталозі repo_copy, з використанням протоколу svn://:

 

>>svn co svn://127.0.0.1/E:/.../repo E:\...\repo_copy;

 

- модифікація РК;

- внесення змін із РК до репозитарію – виконання операції злиття, коли до репозитарію додаються нові файли та каталоги, зокрема здійснюється заміщення файлів та каталогів новими ревізіями. Для цього виконується команда svn commit, разом із зазначенням рядка-ідентифікатора операції злиття. Наприклад, команда svn commit –m "1st_commit" здійснює злиття РК та репозитарію, що ідентифікується рядком "1st_commit".

Модифікація РК полягає у виконанні наступних дій (таблиця 2.4):

- оновлення РК до актуальної версії репозитарію – командою svn update. Потреба в цьому ґрунтується на колективному використанні репозитарію – коли певний користувач здійснює commit-операцію, інші РК перестають бути актуальними;

- внесення змін до РК – за рахунок виконання наступних команд: svn add, svn delete, svn copy, та svn move;

- перегляд змін в РК – команди svn status та svn diff;

- виправлення помилок, зроблених при внесенні змін до РК – команда svn revert;

- вирішення локальних конфліктів файлів та каталогів, обумовлених внесенням змін до РК – команда svn resolve;

 

 

Таблиця 2.4 – Деякі команди модифікації РК

 

Порядок виконання роботи

1 Робота з репозитарієм та контроль версій.

1.1 Перейти до власного робочого каталогу, де створити нову директорію logs – для збереження лістингів про виконання роботи.

1.2 Відкрити Far Manager, за допомогою якого перейти до власного робочого каталогу, де переглянути інформацію про версію SVN та доступні команди:

 

>>svn help > 1.02_svn_help.log

 

Зауваження: >> – символ запиту командного рядка, що не підлягає набору.

1.3 Знаходячись у власному робочому каталозі, створити новий репозитарій repo:

 

>>svnadmin create repo

 

1.4 Переглянути вміст створеного однойменного каталогу repo. Замістити вміст конфігураційного файлу conf\svnserve.conf вмістом лістингу 2.1.

1.5 Імпортувати до репозитарію JUnit-проект, створений при виконанні попередньої лабораторної роботи. Для цього слід скористатися протоколом file:/// згідно наступного шаблону:

 

>>svn import f:\path\to\project file:///f:/path/to/repo -m "first import" > logs\1.05_import.log

 

1.6 Переглянути лістинг про результати імпорту проекту до репозитарію у створеному файлі import_log.txt. У випадку успіху лістинг міститиме інформацію про файли та каталоги імпортованого проекту, додані до репозитарію. Лістинг має завершуватись рядком Committed revision 1, де 1 – початковий номер версії проекту, що надалі буде інкрементуватися.

1.7 Переглянути вміст репозитарію проекту у вигляді деревовидної структури:

 

>>svnlook tree repo > logs\1.07_svnlook_tree.log

 

1.8 Переглянути вміст створеного репозитарію у вигляді списку. Для цього слід зазначати повний шлях до каталогу репозитарію, з використанням протоколу file:///:

 

>>svn list file:///f:/path/to/repo logs\1.08.log

 

Або

 

>>svn list file://localhost/f:/path/to/repo

 

1.9 Виконати дії попереднього кроку 2.2.1.8 з використанням протоколу svn://. замість протоколу file:///:

 

>>svn list svn://127.0.0.1/f:/path/to/repo

 

Виникне помилка – неможливість підключення до репозитарію. Аби позбутися її, необхідно спочатку виконати крок 2.2.1.10.

1.10 Для використання протоколу svn://, що надасть змогу користуватися репозитарієм з іншого комп’ютера (наприклад для створення робочої копії) слід попередньо відкрити доступ до репозитарію:

 

>>svnserve –d –r f:\path\to\repo

 

Зауваження: для зазначеної команди svnserve зручно відкрити окреме консольне вікно, яке має залишатися відкритим упродовж подальшого виконання роботи.

За успішного відкриття доступу до репозитарію результат виконання завдання 2.2.1.9 буде ідентичним лістингові 1.8_log.txt.

1.11 Занести до звіту інформацію про призначення прапорців –d та –r використаної команди svnserve.

1.12 У власному робочому каталозі на одному рівні ієрархії із каталогом repo створити нову директорію repo_copy – контейнер робочої копії.

1.13 Для роботи з репозитарієм згідно моделі копіювання/модифікація/злиття, створити робочу копію repo_copy репозитарію repo шляхом використання команди svn checkout або еквівалентної команди svn co:

 

>>svn checkout svn://localhost/f:/path/to/repo f:\path\to\repo_copy > logs\1.13_repo_copy_log.txt

 

За успішного створення РК каталог repo_copy міститиме JUnit-проект, імпортований до репозитарію. У лістингу 1.12_repo_copy_log.txt міститимуться дані про додані файли і каталоги проекту, на що вказуватимуть прапорці А. Завершальний рядок міститиме інформацію про поточну ревізію РК – Checked out revision 1, номер якої наразі співпадатиме із номером версії репозитарію. Подальші маніпуляції мають здійснюватися безпосередньо над РК.

1.14 Модифікувати конфігураційний файл svnserve.conf репозитарію (лістинг 2.1), замінивши значення write поля anon-access значенням none.

1.15 Спробувати створити нову РК repo_copy_2. Прокоментувати одержуваний при цьому лістинг.

Зауваження: для успішного виконання завдання 2.2.1.15 необхідно створити обліковий запис у файлі repo\conf\passwd у форматі логін = пароль.

1.16 Внести до конфігураційного файлу svnserve.conf зворотні зміни.

1.17 Створити в каталозі test робочої копії repo_copy, поряд із вже існуючим файлом test\test\Tester.java, новий файл модульного тесту PiTester.java (лістинг 2.2).

 

//Лістинг 2.2. Клас модульного тесту

package test;

import org.junit.Test;

import calc.*;

import static org.junit.Assert.*;

public class PiTester {

@Test

public void test() {

PiCalc calc = new PiCalc();

assertEquals(calc.getResult(10), pi, 0);

}

public static final double pi = 3.14159265;

}

 

Призначення тесту – перевірка роботи методу getResult() обчислення значення . Додати створений файл до РК:

 

>>svn add PiTester.java

 

Про успіх додавання свідчитиме прапорець А поряд із назвою доданого файлу: A PiTester.java.

 

1.18 Модифікувати файл Tester.java, додавши до нього javadoc-документацію перед визначенням класу Tester:

 

/**

* unit test container for getResult() method

*/

 

1.19 Переглянути стан робочої копії repo_copy:

 

>>svn st –u –v repo_copy > logs\1.19_svn_st.log

 

У списку-лістингу навпроти доданого та модифікованого файлів РК зазначатимуться, відповідно, прапорці A та M (modified).

1.20 Скопіювати вміст файлу Tester.java до нового файлу PiTester.java.

1.21 Видалити модульний тест Tester.java із РК:

 

>>svn del --force Tester.java

 

Індикатором успіху буде прапорець D поряд із назвою видаленого файлу, який з’явиться замість прапорця M: D Tester.java. При цьому файл буде видалено не лише із РК, а й взагалі.

1.22 Відновити втрачений файл Tester.java, скориставшись командою svn revert:

 

>>svn revert Tester.java

 

Видалений файл буде відновлено до початкового стану, визначеного або командою svn co, або останньою командою svn update. Це означає, що додана javadoc-документація буде відсутня.

1.23 Знову виконати завдання 2.2.1.21, після чого створити новий файл Tester.java із копією вмісту файлу PiTester.java, додавши його до РК. При перегляді стану РК навпроти файлу Tester.java має з’явиться новий прапорець R, що означає заміщений (replaced).

1.24 Здійснити злиття модифікованої РК із репозитарієм. Для цього слід виконати команду commit:

 

>>svn commit --force-log -F *.java

 

В результаті злиття буде сповіщено про додавання нового файлу PiTester.java із робочої копії repo_copy до репозитарію repo та про заміщення вже існуючого файлу Tester.java. Номер версії репозитарію при цьому інкрементується: Committed revision 2.

1.25 Оновити раніше створену другу робочу копію repo_copy_2 внесеними до репозитарію модифікаціями, перейшовши до однойменного каталогу та виконавши команду

 

>>svn update

 

У відповідному лістингу, попри інформацію про доданий файл, зазначатиметься також оновлена версія РК: Updated to revision 2.

1.26 Переглянути детальнішу інформацію про поточну версію РК repo_copy_2:

 

>>svn info

 

1.27 Відновити попередню версію РК та переглянути інформацію про неї:

 

>>svn update –r1

>>svn info

 

1.28 Переглянути відмінності між версіями 1 та 2 РК. Для цього у власному робочому каталозі слід створити та виконати командний файл 1.28_svn_diff.cmd із наступним контентом:

 

>>cd repo_copy

>>svn diff -r1:2 > f:\path\to\...\logs\1.27_diff.log

 

Результатом виконання командного файлу має бути вміст лістингу 1.27_diff.log, де символом + позначатимуться додані рядки javadoc-документації завдання 2.2.1.18.

 

1.29 Змінити формат команди svn diff створеного командного файлу, у якості аргументу якої зазначити рядок -r2:1 замість рядку -r1:2. Проаналізувати новий результат виконання командного файлу. Коментарі занести до звіту.

2 Робота з SVN у середовищі NetBeans IDE.

2.1 Запустити NetBeans IDE 8.0, де відкрити створений у попередній лабораторній роботі проект Lab1.1.

2.2 Імпортувати до відкритого проекту файл PiTester.java репозитарію repo. Для цього слід виконати наступне:

– у вкладці Группа обрати позицію Получить... У вікні, що відкриється, слід вказати місцезнаходження створеного репозитарію repo:

 

svn://localhost/f:/path/to/repo

 

Зауваження: при цьому слід впевнитися, що сервер svnserve запущено і доступ до репозитарію repo відкрито.

– натиснувши елемент керування Далее >, слід вказати потрібний каталог test репозитарію (рис. 2.2); встановити прапорець навпроти рядка Пропустить "test" и получить только содержимое; при цьому потрібно також зазначити локальну (цільову) однойменну директорію проекту – для вивантаження вмісту вказаного каталогу репозитарію. Має бути рядок наступного формату:

 

f:\...\Lab1.1\test\test

 

– натиснути Готово;

Зауваження: наступні дії слід виконувати в середовищі Far Manager.

2.3 У каталозі repo_copy для модульного тесту \test\test\PiTester.java лістингу 2.2 створити тестований модуль \src\calc\PiCalc.java (лістинг 2.3).

 

//Лістинг 2.3. Клас тестованого модуля getResult()

package calc;

public class PiCalc {

public double getResult(int n) {

return 0;}

}

 

2.4 Додати створений файл-шаблон PiCalc.java до РК repo_copy, після чого виконати злиття РК із репозитарієм.

2.5 Реалізувати метод getResult() згідно варіанту. Аналогічно до завдання 2.2.1.28, одержати лістинг, в якому додані рядки тіла методу позначатимуться символом + (варіант 1) або – (варіант 2). Провести модульне тестування методу, здійснивши імпорт файлу PiCalc.java до середовища NetBeans.

 

Варіант 1. Обчислити  за формулою Дж. Валліса:

 

 

Варіант 2. Обчислити  за формулою Готфріда Лейбніца:

 

 

 

Питання для самостійної перевірки

1. Дати визначення поняттям репозитарій та робоча копія.

2. Охарактеризувати моделі контролю версій.

3. Навести та прокоментувати архітектуру SVN.

4. Призначення утиліт svn.exe, svnadmin.exe та svnserve.exe.

5. Призначення та параметри конфігураційного файлу svnserve.conf.

6. Прокоментувати протоколи доступу до репозитарію.

7. Команди svn commit та svn checkout. Призначення. Приклади.

8. Команда svn status. Прапорці станів файлів та каталогів.

9. Команди svn list та svnlook tree. Призначення. Приклади.

10. Послідовність кроків для імпорту файлів та каталогів з репозитарію з використанням NetBeans IDE.

 

Протокол

1. Титульний лист.

2. Мета роботи.

3. Результат виконання завдання 2.2.1.11, коментарі до завдання 2.2.1.15, призначення прапорців завдання 2.2.1.19 та коментарі до завдання 2.2.1.29.

4. Відповіді на контрольні питання.

 

Список рекомендованих інформаційних джерел

1. Chacon S. Pro Git / Scott Chacon. – NY.: Apress, 2009. – 288 p.

2. Collins-Sussman B. Version Control with Subversion / B. Collins-Sussman, B.W. Fitzpatrick, C.M. Pilato. – [2nd ed.]. – CA.: O'Reilly Media, Inc, 2008. – 432 p.

2. Управление версиями в Subversion [Електронний ресурс] – Режим доступу: http://svnbook.red-bean.com/nightly/ru/. – Заголовок з екрану.