CVS підтримує історію дерева каталогів з вихідним кодом, працюючи з послідовністю змін. CVS маркує кожну зміну моментом часу, коли воно було зроблено, і ім'ям користувача, які вчинили зміна. Зазвичай людина, яка вчинила зміна, також надає текстовий опис причини, по якій відбулася зміна. Озброївшись всією цією інформацією, CVS може відповідати на такі питання, як
- Хто скоїв дану зміну?
- Коли вони його зробили?
- Навіщо вони це зробили?
- Які ще зміни відбулися в той же самий час?
Перед обговоренням безлічі разнобразних термінів і ідей, давайте поглянемо на основні команди CVS.
CVS зберігає всі зміни в даному проекті в дереві каталогів, званому репозиторієм (repository). Перед тим, як почати використовувати CVS, вам необхідно налаштувати змінну середовища CVSROOT так, щоб вона вказувала на каталог сховища. Той, хто відповідальний за управління конфігурацією вашого проекту, ймовірно, знає, що саме повинна містити в собі ця змінна; можливо навіть, що змінна CVSROOT вже встановлена глобально.
У будь-якому випадку, на нашій системі репозиторій знаходиться в `/ usr / src / master '. В цьому випадку вам слід ввести команди
`Setenv CVSROOT / usr / src / master '
якщо ваш командний інтерпретатор - csh або породжений від нього, або
`CVSROOT = / usr / src / master export CVSROOT '
якщо це Bash або який-либой інший варіант Bourne shell.
Якщо ви забудете зробити це, CVS поскаржиться, якщо ви спробуєте запустити його:
CVS не може працювати в звичайному дереві каталогів; навпаки, ви повинні працювати в каталозі, який CVS створить для вас. Точно так же, як ви передплачуєте книгу з бібліотеки перед тим, як забрати її з собою, вам слід використовувати команду `cvs checkout '. щоб отримати від CVS робоче дерево каталогів. Припустимо, наприклад, що ви працюєте над проектом, званим `httpc '. тривіальним HTTP клієнтом:
Команда `cvs checkout httpc 'означає" Витягти дерево вихідних текстів з ім'ям `httpc' зі сховищ, зазначеного у змінній оточення` CVSROOT ' ".
CVS поміщає дерево в підкаталог `httpc '.
Більшість цих файлів - робочі копії вихідних текстів `httpc '. Однак, підкаталог з ім'ям `CVS '(найперший) має інше призначення. CVS використовує його для зберігання додаткової інформації про кожен файл в цьому каталозі, щоб визначати, які зміни ви внесли в них з тих пір, як витягли їх з репозиторію.
Після того, як CVS створив робоче дерево каталогів, ви можете звичайним чином редагувати, компілювати і перевіряти що знаходяться в ньому файли - це просто файли.
Наприклад, припустимо, що ми хочемо скомпілювати проект, який ми тільки що витягли:
Здається, `httpc.c 'ще не було перенесено на цю операційну систему. Нам потрібно зробити приведення типів для одного з аргументів функції connect. Щоб зробити це, треба змінити рядок 48, замінивши
Тепер компіляція повинна пройти успішно:
. тут знаходиться текст домашньої сторінки Cyclic Software.
Так як кожен розробник використовує свій власний робочий каталог, зміни, які ви робите в своєму каталоги, не стають автоматично видимими всім іншим у вашій команді. CVS не публікує змін, поки вони не закінчені. Коли ви протестуєте зміни, ви повинні зафіксувати (commit) їх в репозиторії і зробити їх доступними іншим. Ми опишемо команду cvs commit далі.
Однак, що якщо інший розробник змінив той же файл, що і ви, і, може бути, навіть змінив ті ж самі рядки? Чиї зміни буде використано? Зазвичай відповісти на це питання автоматично неможливо, і CVS абсолютно точно некомпетентний, щоб приймати такі рішення.
Тому перед тим, як фіксувати ваші зміни, CVS вимагає, щоб вихідні тексти були синхронізовані з усіма змінами, які зробили інші члени групи. Команда cvs update подбає про це:
Так як CVS об'єднав чиїсь ще зміни з вашими вихідними текстами, слід переконатися, що вони все ще працюють:
Тепер, коли ви синхронізували свої вихідні з колегами і протестували їх, ви готові помістити свої зміни в репозиторій і зробити їх видимими іншим розробникам. Єдиний файл, який ви змінили - це `httpc.c '. але в будь-якому випадку можна без побоювання запустити cvs update. щоб отримати від CVS список модифікованих файлів:
Як і очікувалося, єдиний файл, який згадує CVS - це `httpc.c '; CVS каже, що цей файл містить зміни, які ще не були зафіксовані. Ви можете зафіксувати їх так:
Зауважте, що тепер ви зафіксували ваші зміни і їх видно всім іншим членам групи. Коли інший розробник виконує cvs update. CVS внесе ваші зміни в файли в його робочому каталозі.
Тепер ви, можливо, захочете дізнатися, які саме зміни вніс інший розробник в файл `httpc.c '. Щоб побачити журнальні записи для даного файлу, можна використовувати команду cvs log.
Більшу частину тексту тут ви можете ігнорувати; слід тільки звернути увагу на серію журнальних записів після першого рядка рисок. Журнальні записи виводяться на екран в зворотному хронологічному порядку, виходячи з припущення, що недавні зміни зазвичай більш цікаві. Кожен запис описує одну зміну в файлі, і може бути розібрано на складові частини так:
Перед розглядом того, що нам видала ця команда, опишемо, що означає кожна її частина.
-c Задає використання удобочитаем формату видачі змін. (Цікаво, чому це не так за замовчуванням) (1). -r 1.6 -r 1.7 Вказує CVS, що необхідно видати зміни, необхідні, щоб перетворити редакцію 1.6 до редакції 1.7. Ви можете запросити більш широкий діапазон змін; наприклад, -r 1.6 -r 1.8 відобразить зміна, зроблені Фредом, і зміни, зроблені вами трохи пізніше. (Ви також можете замовити видачу змін в зворотному порядку - нібито вони були скасовані - вказавши номери редакцій в зворотному порядку: -r 1.7 -r 1.6. Це звучить дивно, але іноді корисно.) Httpc.c Файл для обробки . Якщо ви не вкажете його, CVS видасть звіт про все каталозі.
Ось що видасть ця команда:
Потрібні деякі зусилля, щоб звикнути до такої подачі інформації, але це безперечно варто того (2).
Цікава частина інформації починається з перших двох рядків, що починаються з *** і ---; вони описують старий і новий файли, що підлягають порівнянню. Решта складається з двох скибок (hunk), кожен з яких починається з рядка з зірочок. Ось перший "шмат":
Ось другий "шмат":
Тут описується додавання двох рядків, що позначається символами `+ '. CVS не виводить старий текст - це було б надлишково. Для опису вилучених рядків використовується подібний формат.
Як і висновок команди diff. висновок команди cvs diff зазвичай називається латкою (patch), тому що розробники традиційно використовували цей формат для поширення виправлень і невеликих новий можливостей. Латка досить читабельна і містить достатньо інформації, щоб застосувати зміни, які вона містить, до текстового файлу. Насправді, команда patch в середовищі UNIX робить з латками саме це.
CVS звертається з додаванням і видаленням файлів так само, як і з іншими змінами, записуючи такі події в історії файлів. Можна дивитися на це так, як ніби CVS зберігає історію каталогів разом з історією файлів.
CVS не вважає, що створені файли повинні опинитися під його контролем; це не так у багатьох випадках. Наприклад, не потрібно записувати історію змін об'єктних і виконуваних файлів, тому що їх вміст завжди може бути відтворено з вихідних файлів (треба сподіватися). Замість цього, коли ви створите новий файл, cvs update маркує цей файл прапором `. ', Поки ви не скажете CVS, що саме ви маєте намір зробити з цим файлом.
Щоб додати файл в проект, спочатку ви повинні створити його, потім використовувати команду cvs add. щоб маркувати його як доданий. Потім при наступному виконанні команди cvs commit CVS додасть цей файл в репозиторій. Наприклад, ось так можна додати файл README в проект httpc:
CVS звертається з віддаленими файлами майже так само. Якщо ви видалите файл і виконайте `cvs update '. CVS не вважає, що ви маєте намір видалити файл з проекту. Замість цього він надходить милосерднішими - він відновлює останню збережену в репозиторії версію файлу і маркує його прапором U. точно так же, як і будь-який інший оновлення. (Це означає, що якщо ви хочете скасувати зміни файлу в робочому каталозі, ви можете просто видалити його і дозволити команді `cvs update 'створити його заново.)
Щоб видалити файл з проекту, ви повинні спочатку видалити його, а потім використовувати команду `cvs rm '. щоб позначити його для видалення. При наступному запуску команда `cvs commit 'видалить файл з репозиторію.
Фіксування файлу, маркованого за допомогою `cvs rm 'не знищує історію цього файлу - до неї просто додається ще одна редакція ---" не існує ". У репозиторії як і раніше зберігаються всі записи про цей файл, і до них можна звертатися за бажанням - наприклад, за допомогою `cvs diff 'або` cvs log'.
Для перейменування файлу існує кілька стратегій; найпростіша --- перейменувати файл в робочому каталозі, потім виконати `cvs rm 'зі старим іменем і` cvs add' з новим. Недолік цього підходу в тому, що журнальні записи про вміст старого файлу не переносяться в новий файл. Інші стратегії дозволяють уникнути цього, але зате доставляють інші, більш дивні проблеми.
Ви можете додавати каталоги точно також, як і звичайні файли.
Як уже згадувалося, команда `cvs update 'об'єднує зміни, зроблені іншими розробниками, з вихідними текстами в вашому робочому каталозі. Якщо ви відредагували файл одночасно з кимось іншим, CVS об'єднає ваші зміни.
Досить легко уявити собі, як працює об'єднання, якщо зміни були здійснені в різних ділянках файлу, але що якщо ви обидва змінили одну і ту ж рядок? CVS називає цю ситуацію конфліктом і надає вам самому розібратися з ним.
В цьому випадку інший розробник змінив ту саму ділянку файлу, що і ви, тому CVS скаржиться на конфлікт. Замість того, щоб надрукувати M httpc.c. як це зазвичай відбувається, CVS друкує C httpc.c. що означає наявність конфлікту в цьому файлі.
Коли ви вирішите, як саме впоратися з конфліктом, приберіть маркери з коду і внесіть необхідні зміни. В цьому випадку, так як ваша обробка помилок безперечно краще, то просто відкиньте чужий варіант, залишивши такий код:
Тепер протестуйте зміни і зафіксуйте їх:
Важливо розуміти, що саме CVS вважає конфліктом. CVS не розуміє семантики вашої програми, він звертається з вихідним кодом просто як з деревом текстових файлів. Якщо один розробник додає новий аргумент у функцію і виправляє все її виклики, поки інший розробник одночасно додає новий виклик цієї функції, і не передає їй цей новий аргумент, що безумовно є конфліктом - два зміни несумісні - але CVS не повідомили про це. Його розуміння конфліктів строго текстуально.
На практиці, однак, конфлікти трапляються рідко. Зазвичай вони відбуваються тому, що дві людини намагаються впоратися з однією і тією ж проблемою, від нестачі взаємодії між розробниками, або від розбіжностей з приводу архітектури програми. Правильною розподіл завдань між розробниками зменшує ймовірність конфліктів.
Багато системи контролю версій дозволяють розробнику блокувати файл, запобігаючи внесення в нього змін до тих пір, поки його власні зміни не будуть зафіксовані. Незважаючи на те, що блокування доречні в деяких ситуаціях, це не завжди підхід краще, ніж підхід CVS. Зміни зазвичай об'єднуються без проблем, а розробники іноді забувають її розблокувати, в обох випадках явне блокування призводить до непотрібних затримок. Більш того, блокування запобігають тільки текстуальні конфлікти - вони нічого не можуть вдіяти з семантичними конфліктами типу вищеописаного - коли два розробника редагують різні файли.
Цікаво, чому це взагалі не -u. Прим. перев.
Все ж краще використовувати -u. Прим. перев.