- Проблема спільного використання файлів
- Модель "Блокування-Зміна-Розблокування"
- Модель "Копіювання-Зміна-Злиття
Subversion (SVN) - це централізована система для спільної роботи. В її основі лежить сховище, яке містить дані в формі дерева файлової системи - звичайної ієрархії файлів і каталогів. Клієнти підключаються до сховища і читають або змінюють ці файли. Записуючи дані, клієнт робить інформацію доступною для інших. Читаючи дані, клієнт отримує інформацію від інших.
Особливістю сховища SVN є те, що воно "запам'ятовує" будь-яка зміна будь-якого файлу, і навіть зміни в самому дереві каталогів, такі як додавання, видалення і переміщення файлів і каталогів. У будь-який момент клієнт може отримати останню версію дерева файлової системи. Але, крім цього, клієнт має можливість подивитися і попередні стану файлової системи.
Детальна документація по налаштуванню і використанню Subversion доступна тут .
Сховище - центральна база даних, зазвичай розташована на файловому сервері і містить версірованние файли з иx повною історією. Сховище може бути доступно за допомогою різних мережевих протоколів або з локального диска.
Робоча копія - каталог на локальному комп'ютері, з яким працює розробник. Розробник може отримати зі сховища останню версію файлів, попрацювати з нею локально, а коли буде впевнений у змінах - зафіксувати ці файли назад в сховище. Робоча копія не містить історію проекту, але містить копію файлів, які були в сховищі до того, як їх почав змінювати розробник. Таким чином можна дізнатися які саме зміни були зроблені.
ВАЖЛИВО
Зміни можна подивитися тільки для текстових файлів. Для бінарних файлів можна дізнатися тільки сам факт зміни.
Ревізія - стан дерева файлової системи. Фіксація змін дерева файлової системи - це атомарна операція. Тобто розробник може змінити вміст декількох файлів, створити нові каталоги і файли, видалити, перейменувати і скопіювати файли і папки, а потім зафіксувати весь набір зміни як єдине ціле зміна - ревізію.
Ревізії в сховище можна представити у вигляді серії дерев файлової системи - масиву номерів ревізій, який починається з 0 і зростаючого зліва направо (рис. 1). Під кожним номером розташовано дерево файлової системи. І кожне дерево - "знімок" стану сховища після кожної фіксації.
Мал. 1. - Подання ревізій в сховище
ДО ВІДОМА
На відміну від інших систем керування версіями, номери ревізій в Subversion відносяться до дерев цілком, а не до окремих файлів.
Проблема спільного використання файлів
При роботі з SVN може виникнути ситуація, коли два розробника працюють над однією і тією ж функціональністю, реалізованої в одному і тому ж файлі. Якщо перший розробник збереже свої зміни першим, а другий - декількома секундами пізніше, то зміни, внесені першим розробником можуть бути затерті. І хоча ці зміни запам'ятали системою, редагування, внесені першим розробником, будуть відсутні в останній ревізії файлу.
Щоб уникнути подібної проблеми, використовуються дві моделі версірованія:
- модель "Блокування-Зміна-Розблокування";
- модель "Копіювання-Зміна-Злиття".
Модель "Блокування-Зміна-Розблокування"
Сховище дозволяє вносити зміни в файл тільки одному користувачеві за раз. До того як перший користувач зможе внести зміни в файл, він повинен спочатку його заблокувати. Другий користувач не зможе зафіксувати свої зміни до тих пір, поки перший не внесе свої зміни в сховище і не зніме блокування.
недоліки:
- Перший користувач може забути зняти блокування, що призведе до втрати часу другим розробником.
- Блокування може викликати зайву черговість. Якщо користувачі працюють з різними непересічними частинами файлу (наприклад, початок і кінець), то можна було б працювати з файлом одночасно, припускаючи коректне злиття змін.
- Блокування може викликати помилкове відчуття безпеки. Користувачі можуть одночасно працювати з різними файлами, що містять залежить один від одного функціональність. Кожен користувач заблокував свій файл і думає, що починає безпечну ізольовану завдання. Це перешкоджає завчасного обговорення їх змін, які можуть бути несумісні один з одним, що призведе до непрацездатності розробляється рішення.
Ця модель виявляється зручніше, якщо виконується робота над файлами, що не піддаються злиттю. Наприклад, якщо сховище містить зображення, і двоє людей змінюють їх в одне і теж час, то немає можливості злити ці зміни разом.
Модель "Копіювання-Зміна-Злиття
Клієнтську програму кожного користувача зчитує зі сховища проект і створює персональну робочу копію - локальне відображення файлів і каталогів сховища. Після цього користувачі працюють, одночасно змінюючи свої особисті копії. Зрештою, особисті копії зливаються в нову, фінальну версію. Зазвичай система управління версіями виконує злиття автоматично, але в загальному випадку необхідно рішення людини.
Якщо при одночасній роботі двох користувачів зміни перетинаються, то виникає конфлікт. Тоді користувач, який вносить зміни другим, повинен (після обговорення з першим користувачем) вручну з набору конфліктуючих змін вибрати необхідні. Після вирішення конфлікту об'єднаний файл може бути безпечно зафіксований в сховище.
Вирішальним фактором при використанні цієї моделі є взаємодія між користувачами. При поганому взаємодії користувачів збільшується кількість смислових і синтаксичних конфліктів.
У службовій папці .svn робочої копії для кожного файлу Subversion записує інформацію про двох найважливіших властивості:
- на який ревізії заснований файл в робочій копії (робоча ревізія файлу);
- дату і час, коли локальна копія файлу востаннє оновлювалася з сховища.
На підставі цієї інформації Subversion може визначити в якому з станів знаходиться файл робочої копії:
- Чи не змінювався і не застарів. Файл не змінився в робочій копії. У сховищі не фіксувалися зміни цього файлу з часу його робочої ревізії. При спробі його оновити або зафіксувати нічого виконуватися не буде.
- Змінено локально і не застарів. Файл був змінений в робочій копії. У сховищі не фіксувалися зміни цього файлу з часу його базової ревізії. Оновлення виконуватися не буде. Фіксація в сховище виконається успішно.
- Чи не змінювався і застарів. Файл в робочій папці не змінювався, але був змінений в сховище. Файл повинен бути поновлений на відповідності поточної публічної ревізії. Фіксація виконуватися не буде. Оновлення виконається успішно.
- Змінено локально і застарів. Файл був змінений як в робочій папці, так і в сховище. Спроба фіксації зазнає невдачі. Файл необхідно спочатку оновити, спробувавши об'єднати опубліковані іншим розробником зміни з локальними. Якщо Subversion не зможе виконати об'єднання самостійно, рішення конфлікту буде виконувати користувач.
при вимкненому режимі розробки в файлової системі додаток bpm'online використовує власну робочу копію кожного користувача пакету, для якого підключена версійність. Ці робочі копії розміщуються в каталозі, вказаному в елементі defPackagesWorkingCopyPath конфігураційного файлу ConnectionStrings.config (див. " Як розгорнути додаток on-site ").
Якщо включений режим розробки в файлової системі, то робоча копія може бути створена вручну в каталозі [Шлях до встановленої програми] \ Terrasoft.WebApp \ Terrasoft.Configuration \ Pkg \ [Назва пакету] (див. " Створення пакета в режимі розробки в файлової системі ").
Для роботи з Subversion (SVN) в файлової системі рекомендується використовувати клієнтську програму TortoiseSVN версії не нижче 1.9. Воно реалізовано як розширення оболонки Windows і вбудовується в контекстне меню провідника Windows. Детальна документація по використанню TortoiseSVN доступна тут .
