Блокування

Механізм блокування дозволяє одному з розробників захопити в монопольне використання файл або групу файлів для внесення в них змін. На той час, поки файл заблокований, він залишається доступним всім іншим розробникам тільки на читання, і будь-яка спроба внести в нього зміни відкидається сервером. Технічно блокування може бути організована по-різному. Типовим для сучасних систем є наступний механізм.

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

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

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

- сервер перевіряє, чи не заблоковано вже файл іншим розробником; якщо це так, то команда блокування завершується з помилкою «файл заблокований іншим користувачем» і розробник, що викликав її, повинен очікувати, поки інший користувач не зніме свою блокування;

- файл на сервері позначається як «заблокований», із збереженням ідентифікатора який заблокував його розробника і часу блокування;

- якщо блокування на сервері пройшла вдало, на локальній файловій системі з файлу робочої копії знімається атрибут «тільки для читання», що дозволяє почати його редагувати [1].

Розробник працює з заблокованим файлом. Якщо в процесі роботи з'ясовується, що файл змінювати не потрібно, він може викликати команду зняття блокування (unlock, release lock). Всі зміни файлу будуть скасовані, локальний файл повернеться в стан «тільки для читання», з файлу на сервері буде знято атрибут «заблокований» та інші розробники отримають можливість змінювати цей файл.

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

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

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

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

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

<== попередня сторінка	\|	наступна сторінка ==>
Конфлікти та їх вирішення	\|	Версії проекту, теги

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

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