Subversion в дії

URL сховища в Subversion

У книзі для ідентифікації файлів і директорій в сховище Subversion застосовуються URL. В основному, в цих URL використовуються стандартні правила записи, що дозволяють вказувати ім'я сервера і номер порту як частина URL:

Однак, в обробці URL системою Subversion є деякі нюанси, про які потрібно пам'ятати. Наприклад, відповідно до прийнятих угод, URL, який використовує метод доступу file: (цей метод доступу використовується для локальних сховищ), повинен або включати ім'я сервера localhost. або взагалі не містити імені сервера:

Крім того, тим, хто застосовує схему file: на платформі Windows, необхідно використовувати неофіційні «стандартні» правила запису при зверненні до сховища, яке знаходиться на одному комп'ютері, але на різних дисках з клієнтом. Обидві наведені нижче записи будуть працювати; тут X - це ім'я диска, на якому знаходиться сховище:

При другій формі записи для того, щоб вертикальна риска не розцінювалася як канал, необхідно взяти URL в лапки. Також зверніть увагу на використання в URL прямого слеша, незважаючи на те, що рідна (НЕ-URL) форма запису шляху в Windows використовує зворотний слеш.

Ну і нарешті, потрібно сказати про те, що клієнт Subversion при необхідності автоматично кодує URL точно так же, як це робить веб-браузер. Наприклад, якщо URL буде містити пробіл або ASCII-символи в верхньому регістрі:

... то Subversion приховає небезпечні символи і буде вести себе так, як ніби ви надрукували:

Якщо в URL є прогалини, візьміть його в лапки, і тоді командна оболонка обробить це все як один аргумент програми svn.

робочі копії

Ви вже Новомосковсклі про робочих копіях; тепер ми покажемо як клієнт Subversion створює і використовує їх.

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

Як правило, сховище Subversion містить файли (або вихідний код) кількох проектів; зазвичай кожен проект представляється у вигляді підкаталогу файлової системи сховища. При такому підході, призначена для користувача робоча копія зазвичай відповідає окремому подкаталогу сховища.

Наприклад, припустимо, що у вас є сховище, що містить два програмних проекти: paint і calc. Кожен проект розташовується в своєму власному каталозі як показано на Малюнок 1.6, «Файлова система сховища».

Малюнок 1.6. Файлова система сховища

Для того, щоб створити робочу копію, вам потрібно отримати будь-якої з підкаталогів сховища. (Можливо, термін отримати звучить як щось, пов'язане з блокуванням або резервуванням ресурсів, але це не так; дана команда просто створює для вас особисту копію проекту.) Наприклад, якщо ви отримаєте / calc. у вас буде робоча копія на зразок цієї:

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

Отримати доступ до сховища Subversion можна різними способами - на локальному диску або через ряд мережевих протоколів. Місцезнаходження сховища завжди визначається за допомогою URL. Таблиця 1.1, «URL для доступу до сховища.» Показує відповідність різних URL-схем можливих методів доступу.

Таблиця 1.1. URL для доступу до сховища.

Припустимо, ви внесли зміни в button.c. Так як каталог .svn пам'ятає дату зміни файлу і його оригінальне вміст, Subversion може сказати про те, що ви змінили файл. Subversion не публікує ваших змін, поки ви не накажете це зробити. Публікація ваших змін більш відома як фіксація (або checking in) змін в сховище.

Тепер ваші зміни в button.c. разом з приміткою, що описує ці зміни (а саме: виправлення помилки), зафіксовані в сховище; якщо інший користувач створить робочу копію / calc. він побачить ваші зміни в останній версії файлу.

Припустимо, у вас є партнер, Саллі, яка створила робочу копію / calc одночасно з вами. Коли ви зафіксували зміни в button.c. робоча копія Саллі залишилася незмінною, так як Subversion модифікує робочі копії тільки за запитом користувачів.

Для приведення робочої копії в актуальний стан Саллі може попросити Subversion оновити її робочу копію, використовуючи команду Subversion update. Це включить ваші зміни в її робочу копію, так само як і всі інші зміни, зафіксовані після того, як вона створювала робочу копію.

Висновок команди svn update каже, що Subversion оновила вміст button.c. Зверніть увагу, що Саллі не повинна вказувати, який файл оновити; для визначення файлів, які необхідно привести в актуальний стан, Subversion використовує інформацію в каталозі .svn. а також інформацію зі сховища.

Операція svn commit публікує зміни будь-якої кількості файлів і каталогів за одну атомарному операцію. У своїй робочої копії ви можете змінювати вміст файлів, створювати, видаляти, перейменовувати і копіювати файли і каталоги, а потім зафіксувати всі зміни за одну атомарному транзакцію.

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

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

Малюнок 1.7, «Сховище» відмінно ілюструє сховище. Уявіть масив номерів правок, що починається з 0, з напрямком зліва направо. Кожен номер правки має відповідне дерево файлів, а кожне дерево являє собою «знімок» того, як сховище виглядало після фіксації.

Малюнок 1.7. сховище

Глобальні номери правок

На відміну від більшості систем управління версіями, номера правок в Subversion відносяться до всіх. а не тільки до окремо взятих файлів. Кожен номер правки відповідає цілому дереву, окремим станом сховища після зафіксованого зміни. Інакше кажучи, правка N представляє стан файлової системи сховища після виконання N-ой фіксації. Коли користувачі Subversion говорять про «виправлення 5 foo.c». насправді мова йде про «foo.c входить в правку 5». Зауважте, що правки N і M файлу не обов'язково будуть відрізнятися! Багато системи управління версіями ісполюзуют пофайлово нумерацію правок, так що цей підхід на перших порах може здатися незвичним. (Колишні користувачі CVS можуть звернутися за більш детальною інформацією до Додаток B, Subversion для користувачів CVS.)

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

На даний момент робочий каталог повністю відповідає правці 4 в сховище. Припустимо, що ви внесли зміни в button.c і зафіксували ці зміни. При відсутності інших фіксацій ваша фіксація створить правку під номером 5, і тепер ваша робоча копія виглядає наступним чином:

Припустимо, що після цього Саллі фіксує зміни integer.c. створюючи правку 6. Якщо ви скористаєтеся svn update для приведення своєї робочої копії в актуальний стан, то вона стане виглядати так:

Зміни, внесені Саллі в integer.c будуть відображені у вашій робочій копії, і ваші зміни в button.c також будуть присутні. У цьому прикладі текст Makefile в поправках 4, 5 і 6 ідентичний, однак Subversion проставляє номер правки 6 для вашої робочої копії Makefile. щоб показати що файл не застарів. Таким чином, після того як ви виконаєте повне оновлення вашої робочої копії, вона буде повністю відповідати поточному стану сховища.

Як робочі копії відстежують сховище

У службовому каталозі .svn / для кожного файлу робочого каталогу Subversion записує інформацію про двох найважливіших властивості:

на який правці заснований ваш робочий файл (це називається робоча правка файлу), і

тимчасової (наголос на останній склад) мітці, що визначає, коли робоча копія останній раз оновлювалася з сховища.

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

Чи не змінювався і не застарів

Файл не змінився в робочому каталозі, а в сховищі також не фіксувалися зміни цього файлу з часу створення його робочої правки. Команди svn commit і svn update ніяких операцій робити не будуть.

Змінювався локально і не застарів

Файл був змінений в робочій копії, але в сховище не фіксувалися зміни цього файлу останнього оновлення робочої копії. Є локальні зміни, які не були зафіксовані в сховище, тому svn commit виконає фіксацію ваших змін, а svn update зробить нічого.

Чи не змінювався і застарів

Змінювався локально і застарів

Може здатися, що стежити за актуальним станом робочої копії складно. Це не так. Для того, щоб дізнатися про стан будь-якого елементу у вашій робочій копії, існує команда svn status. За більш детальною інформацією про цю команду зверніться до «svn status».

Змішування правок в робочих копіях

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

Оновлення та фіксації відокремлені один від одного

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

Припустимо, у вас є робоча копія, яка цілком відповідає правці 10. Після зміни файлу foo.html. ви виконуєте команду svn commit. яка створює в сховище правку 15. Після виконання фіксації велика частина новачків очікують, що вся робоча копія буде мати правку 15, проте це не так. Між правками 10 і 15 в сховище могло бути внесено будь-яку кількість змін. Так як команда svn update не виконувалася, а svn commit не завантажує змін, клієнт нічого не знає про що знаходяться в сховищі зміни. З іншого боку, якби команда svn commit автоматично завантажувала останні зміни, то всієї робочої копії можна було б призначити відповідний номер правки - 15. Однак це порушило б фундаментальне правило, згідно з яким «передача» і «отримання» є незалежними операціями. Отже, все, що може зробити клієнт Subversion, це помітити один файл - foo.html - як відповідний правці 15. Решта робоча копія продовжує відповідати правці 10. Тільки при виконанні svn update будуть завантажені останні зміни, і вся робоча копія буде позначена як відповідна правці 15.

Змішування правок - це нормально

Часто нові користувачі навіть не підозрюють про те, що їхня робоча копія містить змішані правки. Це може збити з пантелику, так як багато команд клієнта чутливі до робочої правці елемента, з яким він працює. Наприклад, команда svn log використовується для виведення історії зміни файлу або каталогу (див. «Svn log»). Коли користувач викликає цю команду стосовно об'єкту робочої копії, він очікує побачити повну історію цього об'єкта. Однак якщо робоча правка об'єкта дуже стара (через те, що команда svn update довго не виконувалася) буде показана історія для старішої версії цього об'єкта.

Змішування правок - це корисно

Якщо у вас дуже великий проект, ви можете знайти корисним час від часу примусово «повертати» частини робочої копії до більш раннім правок; як це робиться, ви дізнаєтеся в Глава 2, Екскурсія по Subversion. Можливо, ви захочете протестувати більш ранню версію модуля, що знаходиться в підкаталозі або точно дізнатися, коли в конкретному файлі з'явилася помилка. Це - «машина часу». той аспект системи управління версіями, який дозволяє переміщати в історії будь-яку частину робочої копії вперед і назад.

Змішування правок має обмеження

Незважаючи на те, що в робочій копії можна використовувати змішування правок, у цій гнучкості існують обмеження.

По-перше, не можна зафіксувати видалення застарілого файлу або каталогу. Якщо в сховище існує новіша версія елемента, спроба видалення буде відхилена для запобігання можливості ненавмисного знищення змін про які ви не в курсі.

По-друге, не можна зафіксувати зміну метаданих для неоновлення каталогу. Про присвоєння «властивостей» елементам ви дізнаєтеся в Глава 3, Професійне використання Subversion. Робоча правка каталогу визначає конкретний набір входять до неї елементів і властивостей, тому фіксація змін властивостей для застарілого каталогу може призвести до знищення властивостей, про які ви не знаєте.