Текст:CVS:Краткое введение

Глоссарий

CVS-модуль

Модуль с точки зрения CVS — это отдельный блок информации, который весь целиком может быть запрошен пользователем. Также можно устраивать ссылки из одного модуля на другие. Обычно для каждого проекта или группы проектов заводится свой CVS-модуль.

конфликт

Если два пользователя одновременно изменяют один и тот же файл, то возникает конфликт — изменения обоих пользователей должны быть отражены на сервере. Тот, кто первым закрепил файл на сервере — у него все проходит как обычно. Когда второй пытается свои изменения пронести на сервер, то ему сообщается о конфликте и производится попытка автоматического слития исправлений. Если исправления были в разных местах, то автоматика работает верно. Если же исправления попали в одно место, то необходимо вручную разобрать данный конфликт и собрать верную версию. Это возлагается на плечи второго, кто закрепляет изменения.

Sticky tag

Таг, который показывает номер замороженной версии файла на локальном месте. Если он был установлен, то это означает, что пользователь загружал старую версию данного файла. Также этот таг используется при регистрации веток. Если мы создаем ветку и помечаем ее тагом, то когда мы выдергиваем эту ветку, этот таг на локальном месте будет установлен в таг этой ветки, что позволит в дальнейшем вести работу только с выдернутой веткой.

Структура информации под CVS

Система контроля версий позволяет вести конкурентную работу с набором текстовых файлов.

 edge [dir="both"];
 CVS [label="CVS-репозитарий"];
 CVS->"Пользователь 1";
 CVS->"Пользователь 2";
 CVS->"Пользователь 3";
 CVS->"Пользователь 4";

}.

Все файлы расположены в специальном хранилище - Репозитории CVS, который может размещаться на отдельном выделенном сервере (предпочтительный вариант работы), но может размещаться и на локальном компьютере пользователя (учет версий может быть удобен и в случае однопользовательской работы.

К файлам из Репозитория, возможен доступ только через интерфейс системы CVS:

1. запрос текущей версии (или любой другой) файла на локальный диск;
2. внесения изменений в файл;
3. записи измененного файла обратно на сервер как новой версии.

При этом системой обеспечивается хранение всех версий файла, регистрация изменений от лица конкретного пользователя с точностью до строки, а также отслеживание возникших конфликтов.

CVS эффективно работает с текстовыми файлами, позволяя делать построчное сравнение версий, может также использоваться для хранения двоичных файлов, но, естественно, без сервиса по сравнению версий. Кроме того, если текстовые файлы хранятся довольно эффективно, то есть, фактически, имеется одна версия и журнал изменений, то двоичный файл при каждой правке запоминается целиком.

После получения последней версии файлов проекта с сервера большая часть работы сводится к следующим основным действиям:

1. внесение изменений в файл каким-либо редактором;
2. проверка, что изменения не привели проект в негодность (например, что при компиляции не происходит ошибок);
3. закрепление изменений (пронесение изменений в репозитарий на сервере).

Помимо простейшего цикла работы у CVS есть множество дополнительных возможностей.

Основной цикл работы с CVS

Под основным циклом работы понимается использование стандартных команд CVS, позволяющих читать файлы, изменять их и записывать изменения.

Каждый CVS-модуль (полное дерево каталогов), помещенный под контроль CVS, хранится в центральном репозитарии. Вся работа выполняется с локальной копией CVS-модуля изменения из которой переносятся в репозитарий по готовности. Для этого используется несколько основных команд.

checkout

Для создания локальной копии CVS-проекта необходимо выбрать каталог для проектов на локальном диске (напр. D:\projects), в котором будет создан подкаталог данного проекта. В этом каталоге выполнить команду

cvs checkout имя_проекта

После этого в каталоге D:\projects\имя_проекта появляется локальная копия всего дерева последней версии указанного проекта.

Возможные значения параметра имя_проекта можно увидеть простым просмотром файла CVSROOT/modules, который можно запросить командой:

cvs checkout CVSROOT

commit

После того, как проверено, что внесенные Вами изменения оставили проект в рабочем (по крайней мере, в компилируемом) состоянии, следует закрепить изменения в репозитарии. В принципе, можно использовать разную политику закрепления изменений (как можно чаще, как можно реже, только после успешной компиляции и т. д.). Выбор конкретной политики не влияет на работу самого CVS и обусловлен требованиями проекта. Закрепление изменений производится командой:

cvs commit -m "[Комментарий]" [file]

либо не указывая имя файла, что закрепляет все изменения в выбранной директории. Если не указан комментарий, то CVS запускает редактор для ввода пояснений в журнал версий.

Возможно, что изменения вносились в старую версию файла и с тех пор файл был поправлен. Об этом cvs commit выдаст сообщение:

cvs server: Up-to-date check failed for `file'
cvs [server aborted]: correct above errors first!

и надо будет выполнить cvs update для конфликтного файла, а затем, возможно, разрешить конфликт (процедура описана ниже). Если одновременно закрепляются изменения в нескольких файлах, то если конфликт был в одном из них, то все закрепление сделано не будет.

update

Синхронизация с репозитарием может быть выполнена в любой момент командой

cvs update [-dP] [file]

Ключ -d используется для проноса новых директорий, появившихся в проекте. Ключ -P удаляет пустые директории.

Дело в том, что в CVS нельзя удалить директорию. Можно лишь убрать все файлы из директории, тогда по команде cvs update -P она будет стерта с локальной машины.

Данная команда является одной из самых безопасных, так как ничего не меняет на сервере. Отметим также, что если файл на локальном компьютере был испорчен по каким-либо причинам, например неверно отредактирован, то его можно восстановить удалив его на локальной машине и заново считав с сервера командой cvs update [file].

При работе команда cvs update выдает протокол действий в виде списка имен файлов, предваряемых одной буквой — статусом файла. Значения букв:

U,P

В файл внесены изменения из репозитария.

M

Локальный файл модифицирован относительно репозитария.

C

Изменения локального файла конфликтуют с правками в репозитарии.

?

Файл не помещен под CVS.

А

Файл локально добавлен, а в репозитарий не помещен.

R

Файл удален, но изменения в репозитарий не пронесены.

Проект может содержать директории, которые образованы специальным образом ссылкой на директории со стандартными файлами. Команда cvs update не копирует такие директории в вашу локальную копию проекта. Такие директории копируются командой

 cvs checkout имя_проекта

то есть той же командой, которая используется для создании копии проекта.

Если в директории завести файл с именем .cvsignore и поместить в него список шаблонов файлов, которые не должны помещаться под CVS, то на них «?» выдаваться не будет.

Если было внесено много исправлений и команда выдала большой список, ее можно запустить повторно — она выдаст только файлы с модификациями и конфликтами. Конфликт означает, что правки файла, сделанные пользователем локально конфликтуют с правками, внесенными в репозитарий кем-то еще. Соответствующие места в файле будут помечены:

<<<<<<< filename
 Текст из локального файла
=======
 Текст из репозитария
>>>>>>> version

Перед закреплением изменений необходимо эти конфликты разрешить.

add

Добавление директории или файла выполняется командой

cvs add file.txt

Для файла необходимо затем выполнить cvs commit.

Под CVS можно хранить также бинарные файлы, хотя и не так эффективно, как текстовые, т. к. в этом случае, CVS будет полностью хранить каждую версию файла. Бинарные файлы добавляются с опцией «-kb»:

cvs add -kb file.jpg

remove

Для удаления файла выполняются команды:

cvs remove -f file
cvs commit -m "[комментарий]" file

Заметим, что команда cvs remove требует, чтобы либо файл был сначала удален из локального каталога, либо была вызвана с опциями, форсирующими удаление локального файла, т.е. cvs remove -f code.sql.

release

Если вдруг возникла необходимость убрать файлы из локальной CVS директории, то необходимо делать это командой:

cvs release -d имя_проекта

в основном каталоге проекта. При этом производится проверка соответствия локальной директории и состояния репозитария. Если есть конфликтующие или расходящиеся файлы, то будет выдана диагностика о их наличии. Все расхождения нужно проанализировать и устранить. После этого необходимо повторно выполнить ту же команду, проверить, что измененных файлов нет, и ответить на задаваемый вопрос «Y». После этого все файлы проекта будут удалены.

Правила работы с CVS

При использовании CVS нужно придерживаться нижеописанных правил:

• Рекомендуется с утра делать cvs update на всю директорию с проектами, чтобы не пропускать новые версии.
• Все полезные изменения вечером должны быть отражены в репозитарии. Исключением являются программные тексты, которые не были до конца исправлены (не компилируются, ошибки при тестировании).
• При выполнении cvs commit нужно всегда вводить комментарии. Если есть система регистрации ошибок или заданий (например Bugzilla или Jira), то качестве комментария при cvs commit удобно использовать не текстовое описание проблемы и исправлений, а код ошибки или задания, типа «Bug 1234».
• Обязательно нужно просматривать результат cvs commit, чтобы не пропустить сообщение о конфликте.
• Нельзя получать новые версии файлов другим путем, кроме как выполнением команд update или checkout. Копирование новых версий файлов с другого компьютера может привести к потере данных!

Расширенные возможности CVS

Рассмотрим функции и команды CVS, хотя и относительно редко используемые, но полезные во многих специальных случаях.

log

Для того, чтобы получить историю работы с файлом, нужно использовать команду

cvs log [file]

Результат работы рекомендуется перенаправлять в отдельный файл, который потом смотреть в произвольной кодировке. Выдается история изменений данного файла с номерами версий и пользователями, которые закрепляли данные версии.

update

Для того, чтобы получить конкретную версию файла, необходимо набрать команду

cvs update -r номер_версии file

Из репозитария будет загружена версия с данным номером. Если в файле на локальном компьютере производились изменения, то они будут слиты с версией с запрашиваемым номером, что может привести к странным результатам и, обычно, после этого требуется устранить конфликт.

липкие метки

Локальный файл, который был получен путем считывания предыдущей версии считается замороженным (имеющим «sticky tag») и изменения в нем не будут закрепляться в репозитарии. Проверить наличие этого тага можно путем вызова команды для получения статуса файла

cvs status [file]

В результате исполнения выдается полная информация о версиях данного файла.

Для того, чтобы вернуться к последней версии файла, необходимо набрать команду

cvs update -A file

Команда обеспечивает снятие всех «sticky tag» с выбранного файла, она также синхронизирует файл с последней версией с сервера. Если мы вдруг произвели изменения в файле с установленным «sticky tag», то изменения не будут потеряны — они будут пронесены в последнюю версию файла, при этом естественно возникнет конфликт.

diff

Для просмотра изменений файла от версии к версии нужно вызвать команду

cvs diff -r версия_1 [-r версия_2] file

Вторую версию можно не указывать, тогда будет взят текущий файл. Результат следует перенаправлять в отдельный файл. В файле будет приведен список отличий между версиями.

annotate

Для того, чтобы посмотреть, кто что написал в файле, необходимо использовать команду

cvs annotate file

Результат надо направлять в файл. В результате, для каждой строки исходного файла будет выведено имя пользователя и версия, в которой появилась данная строка.

Управление ветками под CVS

Для поддержки нескольких версий описаний библиотек, либо стандартов на разработку, необходимо использовать наиболее сложные возможности CVS — систему веток.

Путь развития каждого файла под CVS может представлять собой дерево (вообще говоря, даже многопотоковый граф). От основного ствола — основного пути изменения файла можно отщепить произвольное количество веток. На определенном этапе развития ветки могут быть снова слиты в одну ветку.

 "file.cpp 1.1"->"file.cpp 1.2"->"file.cpp 1.3 REL1_0";
 "file.cpp 1.3 REL1_0"->"file.cpp 1.3.1 patches"->"file.cpp 1.3.1.1 Bug 221";
 "file.cpp 1.3 REL1_0"->"file.cpp 1.4"->"file.cpp 1.5 REL2_0";
 "file.cpp 1.3.1.1 Bug 221"->"file.cpp 1.5 REL2_0" [label="merge",fontsize=8,fontcolor=blue];

}.

Для отщепления ветки используется механизм пометки тагами. Версия файла может быть помечена произвольным количеством тагов, таг — строка произвольного вида. Для данного файла существует одна и только одна версия помеченная конкретным тагом. Если мы хотим пометить тагом другую версию, то мы должны снять этот таг с предыдущей версии.

Для проекта таги используются для пометки определенных срезов информации. Эти срезы могут перемещаться и изменяться со временем.

Помимо обычных тагов бывают таги веток. Если мы хотим завести новую ветку у файла, то мы обязаны пометить ее веточным тагом. Отметим, что при поиске файла с тагом неважно, ищем мы файл по веточному тагу, либо по обычному.

Когда ветка выделена — она продолжает развиваться независимо, при этом последняя версия файла ветки помечена тагом этой ветки.

Для пометки файла тагом нужно использовать команду

cvs tag -F таг

Она пометит все файлы в директории и поддиректориях указанным тагом. Использование -F позволяет сдвигать таг, если он раньше был установлен.

Для того, чтобы создать ветку, нужно вызвать нижеследующие команды. Сначала нужно считать версию файла помеченную данным тагом — для проверки.

cvs update -r таг_ветки file

Далее следует проверить таг и признак тага — может быть ветка уже была создана. Также нужно проверить номер версии файла — отсюда ли мы хотим делать ветку. Вызвав команду

cvs status file

произведем проверку. Если мы хотим делать ветку из другого места, то мы должны считать нужную версию файла и сделать веткой при помощи команды

cvs tag -F -b таг_ветки file

Команда создает ветку этого файла для стандарта с данным номером. Опция -F означает, что старый таг с этим именем будет удален.

Для того, чтобы считать ветку файла, необходимо вызвать команду

cvs update -r таг_ветки

При этом на локальную машину будет помещены файлы из этой ветки, а за отсутствием файла в этой ветке — из основного ствола.

После этого локальная машина начинает работать с данной веткой. Команда update будут считывать более новые файлы этой ветки.

Для взятия последней версии основного ствола нужно использовать команду

cvs update -A file

Администрирование репозитария

Под администрированием репозитария понимается действия по созданию, удалению и импорту репозитария и отдельных CVS-модулей.

Создание CVS-модуля:

• Создать директорию с названием проекта (CVS-модуля). Директорию можно создавать в любом месте локальной машины.
• Внутри директории выполнить команду

 cvs import custis/path vendortag releasetag

где

path

место CVS-модуля внутри репозитория, например, для модулей документации — docs/projects/имя_проекта;

vendortag

создатель модуля.

releasetag

идентификатор, определяющий версию проекта. Идентификатор должен начинаться с буквы и не должен содержать символов @,$,-.

Пример такой команды

cvs import custis/projects/adb CUSTIS ADB_0_0

• Удалить на локальной машине созданную директорию.
• Создать локальную копию CVS-проекта CVSROOT/modules, для чего в корневой директории выполнить команду

cvs checkout CVSROOT/modules

• В файле projects/CVSROOT/modules в нужное место вставить название модуля и его место в репозитории, используя имеющиеся там примеры. Место в репозитории должно совпадать с путем, указанном в команде import.
• Записать изменения файла projects/CVSROOT/modules в репозиторий с помощью команды cvs commit.
• Удалить модуль CVSROOT с локальной машины командой

 cvs release -d CVSROOT

• Создать локальную копию проекта командой checkout, убедиться, что все правильно.

Тесты

Можете проверить свои знания CVS интерактивной системой тестирования:

• Тест Шаблон:Cis-test;
• Тест Шаблон:Cis-test.

По крайней мере часть этого текста взята с ресурса http://lib.custis.ru/ под лицензией GDFL.Список авторов доступен на этом ресурсе в статье под тем же названием.