Etc.: CVS – Система Управления Параллельными Версиями

Справочник по административным файлам

В репозитории CVS в каталоге `$CVSROOT/CVSROOT/' находится несколько вспомогательных файлов. При работе с CVS эти файлы можно и не использовать, но, будучи правильно настроенными, они способны сильно облегчить вам жизнь. Методика редактирования таких файлов обсуждается в section Справочник по административным файлам.

Самым важным таким файлом является `modules', которые описывает модули, находящиеся в репозитории.

Файл `modules'

В файле `modules' находится описание модулей, то есть коллекций исходных текстов. Файл модулей можно редактировать обычным для административных файлов способом.

Файл `modules' может содержать пустые строки и комментарии (строки, начинающиеся с `#'), а также описания модулей. Длинные описания можно разбивать на несколько строк, используя обратную косую черту (`\') в качестве последнего символа в строке.

Существует три основных типа модулей: модули-синонимы, обычные модули и амперсенд-модули. Разница между ними заключается в способе сопоставления файлов в репозитории файлам в рабочем каталоге. В нижеприведенных примерах в репозитории находится каталог `first-dir/', содержащий два файла, `file1' и `file2', а также каталог `sdir/'. `first-dir/sdir/' содержит также файл `sfile'.

Модули-синонимы

Модули синонимы -- это самый простой вид модулей:

mname -a aliases...: Это -- простейший путь описания модуля mname. Флаг `-a' означает, что новый модуль будет лишь синонимом для указанного списка модулей: CVS будет обращаться с mname, указанным в командной строке, точно так же, как если бы вместо него был указан список aliases. aliases может содержать имена других модулей или имена каталогов. При использовании имен каталогов CVS создает промежуточные каталоги в рабочем каталоге, как если бы путь был задан явно в командной строке.

Например, если файл `modules' содержит строку

amodule -a first-dir

то следующие две команды эквивалентны:

$ cvs co amodule
$ cvs co first-dir

и обе выдадут одинаковые сообщения:

cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile

Обычные модули

mname [ options ] dir [ files... ]: В простейшем случае эта форма описания модуля сокращается до `mname dir'. В этом случае файлы в каталоге dir становятся модулем mname. dir -- путь к каталогу с исходными текстами, относительно $CVSROOT. При извлечении исходных текстов в рабочем каталоге создается каталог mname; по умолчанию не используются промежуточные каталоги, даже если dir состоит из нескольких уровней каталогов.

Например, если модуль описан как

regmodule first-dir

то regmodule будет содержать файлы из `first-dir/':

$ cvs co regmodule
cvs checkout: Updating regmodule
U regmodule/file1
U regmodule/file2
cvs checkout: Updating regmodule/sdir
U regmodule/sdir/sfile
$

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

regfiles first-dir/sdir sfile

При таком описании извлечение модуля regfiles создает единственный рабочий каталог `regfiles', содержащий указанный файл, который берется из каталога `first-dir/sdir/', находящегося в репозитории:

$ cvs co regfiles
U regfiles/sfile
$

Амперсенд-модули

Описание модуля может ссылаться на другие модули, используя запись `&module'.

mname [ options ] &module...

При извлечении такого модуля для каждого амперсенд-модуля создается соответствующий подкаталог. Например, если файл `modules' содержит строчку

ampermod &first-dir

то при извлечении будет создан каталог `ampermod/', содержащий каталог, который называется `first-dir/', который, в свою очередь, содержит все каталоги и файлы, находящиеся в этом каталоге. Например, команда

$ cvs co ampermod

создаст следующие файлы:

ampermod/first-dir/file1
ampermod/first-dir/file2
ampermod/first-dir/sdir/sfile

В реализации CVS есть одна ошибка: сообщения, которые выдает CVS, не содержат упоминания `ampermod/', и поэтому неправильно сообщают о местонахождении извлеченных файлов:

$ cvs co ampermod
cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile
$

Не полагайтесь на такое ошибочное поведение; в будущих версиях CVS оно может быть исправлено.

Исключение каталогов из списка

Модуль-синоним может исключить определенные каталоги из модулей, используя восклицательный знак (`!') перед именем каждого исключенного каталога.

Например, если файл `modules' содержит

exmodule -a !first-dir/sdir first-dir

то при извлечении модуля `exmodule' будут извлечено все содержимое `first-dir/', кроме файлов из каталога `first-dir/sdir'.

Флаги модулей

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

-d name: Дать рабочему каталогу другое имя, отличающееся от имени модуля.
-e prog: Задает программу prog, которая выполняется при экспорте модуля. prog выполняется с единственным аргументом, именем модуля.
-i prog: Задает программу prog, которая выполняется, когда изменения в файлах модуля помещаются в репозиторий. prog выполняется с полным именем соответствующего каталога (??? а не файла?) в репозитории. Файлы `commitinfo', `loginfo' и `verifymsg' обеспечивают дополнительные способы выполнения программ при фиксировании.
-o prog: Задает программу prog, которая выполняется, когда файлы модуля извлекаются в рабочий каталог. prog выполняется с единственным аргументом, именем модуля.
-s status: Задает статус модуля. Когда файл модулей выдается на экран с помощью `cvs checkout -s', модули в нем отсортированы по статусу, а затем по имени модуля. Этот ключ не имеет какого-либо другого значения. Этот ключ можно использовать для нескольких вещей, помимо статуса модуля: например, перечислить людей, ответственных за модуль.
-t prog: Задает программу prog, которая выполняется, когда файлы в модуле помечаются с помощью команды rtag. prog выполняется с двумя аргументами: именем модуля и именем метки, указанной в команде rtag. Эта программа не выполняется, когда дается команда tag. Обычно лучше использовать файл `taginfo' (see section Настройка журналирования).
-u prog: Задает программу, которая выполняется, когда команда `cvs update', выполняется в основном каталоге извлеченного модуля. prog выполняется с единственным аргументом, полным путем к указанному модулю в репозитории.

Файл `cvswrappers'

Обертки -- это возможность CVS, позволяющая управлять определенными настройками, основываясь на имени обрабатываемого файла. В список таких настроек входят ключи `-k' для двоичных файлов и `-m' для файлов, которые нельзя автоматически объединять.

Ключ `-m' задает метод объединения, который нужно использовать при обновлении не-двоичного файла. `MERGE' означает обычное поведение CVS: попробовать объединить файлы. `COPY' означает, что cvs update откажется объединять файлы, точно так же, как это происходит с двоичными файлами, описанными с помощью ключа `-kb' (если файл описан как двоичный, то использовать `-m 'COPY'' необязательно). CVS предоставит пользователю две версии файлов, и потребует вручную внести необходимые изменения, пользуясь внешними по отношению к CVS инструментами. Предупреждение: не используйте `COPY' с CVS версии 1.9 и раньше -- они просто перезапишут один файл поверх другого, уничтожая старое содержимое. Ключ `-m' влияет только на поведение при обновлении, не затрагивая способ хранения файла. См. section Обработка двоичных файлов, где описана работа с ними.

В основном формат файла `cvswrappers' таков:

маска_файла     [ключ значение][ключ значение]...

где ключ -- это

-m: способ обновления (`MERGE' или `COPY')
-k: способ подстановки ключевых слов. Подробности в See section Подстановка ключевых слов.

а значение заключено в одиночные кавычки.

Например, нижеследующая команда импортирует каталог, считая файлы, заканчивающиеся на `.exe', двоичными:

cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag

Выполнение программ на разных стадиях фиксирования

Флаг `-i' в файле `modules' может использоваться для выполнения определенной программы, когда соответствующие файлы помещаются в репозиторий (see section Файл `modules'). Файлы, описанные в этой секции, обеспечивают другие, более гибкие способы выполнения программ при фиксировании.

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

`commitinfo': Программа, ответственная за проверку, разрешена ли команда фиксирования изменений. Если эта программа заканчивается с ненулевым кодом завершения, фиксирование будет прервано.
`verifymsg': Указанная программа используется для проверки журнального сообщения, чтобы убедиться, что оно содержит все требуемые поля. Полезно использовать этот файл в комбинации с `rcsinfo', который может содержать шаблон журнального сообщения (see section Файл rcsinfo).
`editinfo': Заданная программа используется для редактирования журнального сообщения, и, возможно, проверки, что оно содержит все требуемые поля. Это особенно полезно в комбинации с файлом `rcsinfo', который может содержать шаблон журнального сообщения (see section Файл rcsinfo). Устарело.
`loginfo': Указанная программа вызывается, когда завершено фиксирование. Она получает журнальное сообщение и дополнительную информацию, и может сохранить сообщение в файле, отправить его по почте ответственному человеку, поместить в местной группе новостей, или... Пределом является только ваше воображение!

Обычный синтаксис

Административные файлы, такие как `commitinfo', `loginfo', `rcsinfo', `verifymsg', и т. д., все имеют общий формат. Назначение этих файлов описано позднее, а здесь описан их общий синтаксис.

Каждая строка содержит следующее:

Регулярное выражение: простое регулярное выражение, использующее синтаксис GNU emacs.
Разделитель -- один или больше пробелов или символов табуляции.
Имя файла или шаблон командной строки.

Пустые строки игнорируются. Строки, которые начинаются с символа `#', считаются комментариями. Длинные строки, к сожалению, не могут быть разбиты на части.

Используется первое регулярное выражение, которое совпадает с именем текущего каталога в репозитории. Остаток строки используется, соответственно, как имя файла или командная строка.

Файл `commitinfo'

Файл `commitinfo' описывает программы, которые выполняются перед тем, как команда `cvs commit' выполняет свою работу. Эти программы используются перед фиксированием изменений для проверки, чтобы измененный, добавленные и удаленные файлы действительно готовы к фиксированию. Это можно использовать, например, чтобы убедиться, что измененные файлы соответствуют стандартам кодирования, принятым в вашей организации.

Как упоминалось ранее, каждая строка в файле `commitinfo' состоит из регулярного выражения и шаблона командной строки. Шаблон может включать имя программы и аргументы, которые вы хотите передать этой программе. К шаблону добавляется полный путь к текущему репозиторию, за которым следуют имена файлов, участвующих в фиксировании (добавленные, удаленные и измененные).

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

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

Помимо совпадающих строк, используются также все строки, начинающиеся с `ALL'.

Замечание: когда CVS обращается к сетевому репозиторию, `commitinfo' будет выполняться на сервере, а не на клиенте (see section Сетевые репозитории).

Проверка журнальных записей

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

Файл `verifymsg' полезнее всего использовать вместе с файлом `rcsinfo', который используется в качестве шаблона журнального сообщения.

Каждая строка в файле `verifymsg' состоит из регулярного сообщения и шаблона команды. В шаблоне должно присутствовать имя программы и, возможно, несколько аргументов. К шаблону добавляется полный имя файла с шаблоном журнального сообщения.

Следует заметить, что ключевое слово `ALL' не поддерживается. Если найдено более одной совпадающей строки, используется первая. Это полезно для указания скрипта проверки, используемого по умолчанию, а затем переопределения его в подкаталоге.

Если имя репозитория не совпадает ни с одним регулярным выражением в этом файле, то используется строка `DEFAULT', если она есть.

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

Заметьте, что скрипт верификации не может изменять журнальное сообщение, но лишь принимать или отвергать его.

Вот простой пример файла `verifymsg', использующегося вместе с соответствующим шаблоном журнальной записи в файле `rcsinfo' и скриптом проверки этой записи. Сначала --- шаблон журнальной записи. Нам нужно, чтобы в первой строке этой записи находился номер исправленной ошибки. Остаток журнальной записи -- в свободной форме. Вот такой шаблон находится в файле `/usr/cvssupport/tc.template':

BugId:

Скрипт `/usr/cvssupport/bugid.verify' используется для проверки журнального сообщения.

#!/bin/sh
#
#       bugid.verify filename
#
#  Verify that the log message contains a valid bugid
#  on the first line.
#
if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
    exit 0
else
    echo "No BugId found."
    exit 1
fi

Файл `verifymsg' содержит строку:

^tc     /usr/cvssupport/bugid.edit

Файл `rcsinfo' содержит такую строку:

^tc     /usr/cvssupport/tc.template

Файл `editinfo'

ЗАМЕЧАНИЕ: использование `editinfo' устарело. Для задания редактора журнальных записей по умолчанию используйте переменную окружения EDITOR (see section Все переменные окружения, используемые в CVS) или глобальный ключ `-e' (see section Глобальные ключи командной строки) См. section Проверка журнальных записей, где описано, как использовать `verifymsg'.

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

Если в файле `editinfo' не найдено совпадающей строки, используется редактор, заданный переменной окружения $CVSEDITOR. Если эта переменная не установлена, используется переменная окружения $EDITOR. Если и эта переменная не установлена, используется редактор по умолчанию. См. также section Фиксирование изменений.

Файл `editinfo' наиболее полезно использовать вместе с файлом `rcsinfo', который используется в качестве шаблона журнального сообщения.

Каждая строка в файле `editinfo' состоит из регулярного выражения и шаблона команды, состоящего из имени программы и, возможно, нескольких аргументов. К шаблону программы добавляется полное имя текущего шаблона журнального сообщения.

Следует заметить, что ключевое слово `ALL' не поддерживается. Если совпадает более одной строки, используется первая. Это полезно для задания скрипта редактирования по умолчанию, а затем переопределения его в подкаталоге.

Если имя каталога в репозитории не совпадает ни с одним регулярным выражением в этом файле, то используется строка `DEFAULT', если она есть.

Если скрипт редактирования завершается с ненулевым кодом завершения, то процесс фиксирования аварийно завершается.

Заметьте, что когда CVS обращается к сетевому репозиторию, или когда используются ключи `-m' и `-F' команды cvs commit, то файл `editinfo' не используется. Вместо него можно использовать `verifymsg'.

Пример использования Editinfo

Ниже следует небольшой глупый пример файла `editinfo', вместе с соответствующим шаблоном журнального сообщения в файле `rcsinfo' и скрипт редактора. Мы начнем с шаблона журнального сообщения. Предположим, мы хотим хранить номер исправленной ошибки в первой строке журнального сообщения. Остаток журнального сообщения содержит любой описательный текст. В файле `/usr/cvssupport/tc.template' находится такой шаблон:

BugId:

Скрипт `/usr/cvssupport/bugid.edit' используется для редактирования журнального сообщения.

#!/bin/sh
#
#       bugid.edit filename
#
#  Call $EDITOR on FILEname, and verify that the
#  resulting file contains a valid bugid on the first
#  line.
if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
$CVSEDITOR $1
until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
do  echo -n  "No BugId found.  Edit again? ([y]/n)"
    read ans
    case ${ans} in
        n*) exit 1;;
    esac
    $CVSEDITOR $1
done

Файл `editinfo' содержит такую строчку:

^tc     /usr/cvssupport/bugid.edit

Файл `rcsinfo' содержит такую строчку:

^tc     /usr/cvssupport/tc.template

Файл loginfo

Файл `loginfo' используется для управления тем, куда посылается журнальная информация при выполнении `cvs commit'. В левой части строки находится регулярное выражение, с которым совпадает имя каталога, в котором производится изменение, относительно $CVSROOT. Остаток соответствующей строки -- это программа-фильтр, которая получает журнальное сообщение на стандартный ввод.

Если имя в репозитории не совпадает ни с одним регулярным выражением, используется строка `DEFAULT', если она есть.

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

Используется первое совпадающее регулярное выражение.

See section Выполнение программ на разных стадиях фиксирования, где описан синтаксис файла `loginfo'.

Пользователь может использовать в имени команды форматные строки. Такие строки состоят из символа `%', за которым следует пробел, одиночный форматный символ или набор форматных символов, заключенных в скобки `{' и `}'. Форматные символы таковы:

s: имя файла
V: старый номер ревизии (перед фиксированием)
v: новый номер ревизии (после фиксирования)

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

Например, можно использовать форматные строки `%', `%s', `%{s}' и `%{sVv}'.

На выходе образуется строка токенов, разделенных пробелами. Для обратной совместимости первый токен -- это имя репозитория, остальные -- список запрошенных в форматной строке полей, разделенных запятыми. Например, если репозиторий находится в `/u/src/master', форматная строка `%{sVv}', а были изменены три файла, (`ChangeLog', `Makefile' и `foo.c'), то на выходе появится

/u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13

В качестве другого примера: `%{}' означает, что на выходе появится только имя репозитория.

Замечание: когда CVS обращается к сетевому репозиторию, то `loginfo' будет исполнен на стороне сервера, а не на стороне клиента (see section Сетевые репозитории).

Пример использования loginfo

Нижеследующий файл `loginfo' с помощью крохотного скрипта добавляет журнальные сообщения к файлу `$CVSROOT/CVSROOT/commitlog', а также журналирует в `/usr/adm/cvsroot-log' фиксирование изменений в административных файлах. Журнальные записи, соответствующие фиксированию изменений в каталоге `prog1/' отсылаются по почте пользователю `ceder'.

ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log

^prog1          Mail -s %s ceder

Скрипт `/usr/local/bin/cvs-log' выглядит так:

#!/bin/sh
(echo "------------------------------------------------------";
 echo -n $2"  ";
 date;
 echo;
 cat) >> $1

Обновление извлеченной копии

Часто бывает полезно хранить дерево каталогов, содержащее файлы, соответствующие последней версии из репозитория. Например, другие разработчики могут захотеть обращаться к последним версиям исходных текстов без необходимости извлекать их, или же вы можете обслуживать с помощью CVS web-сайт и хотели бы, чтобы каждое зафиксированное изменение приводило бы к обновлению файлов, которые показываются web-сервером.

Можно настроить такое поведение с помощью `loginfo', который будет вызывать cvs update. Если сделать это напрямую, то возникнет проблема с блокировками, поэтому cvs update должен выполняться на фоне. Вот пример для операционной системы UNIX (всё это должно помещаться на одной строке):


^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
 cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

При такой конфигурации фиксирование изменений в каталогах репозитория, которые начинаются с `cyclic-pages' приведет к обновлению извлеченного дерева, находящегося в `/u/www/local-docs'.

Файл rcsinfo

Файл `rcsinfo' может использоваться, чтобы задать форму, которая редактируется при заполнении журнала фиксирований. Файл `rcsinfo' имеет синтаксис, подобный синтаксису файлов `verifymsg', `commitinfo' и `loginfo'. See section Обычный синтаксис. В отличие от остальных файлов, правая часть строки является не шаблоном команды, но полным именем файла, содержащего шаблон журнального сообщения.

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

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

Шаблон журнального сообщения будет использоваться по умолчанию. Если вы зададите журнальное сообщение с помощью `cvs commit -m message' или `cvs commit -f file', то вместо шаблона будет использоваться именно оно.

See section Проверка журнальных записей, где приведен пример файла `rcsinfo'.

Когда CVS обращается к сетевому репозиторию, используется то содержимое файла `rcsinfo', которое было, когда каталог был извлечен в последний раз. Если вы редактируете `rcsinfo' или шаблоны, которые используются в нем, вам потребуется заново извлечь рабочий каталог.

Игнорирование файлов с помощью cvsignore

Есть определенные имена файлов, которые постоянно находятся в вашем рабочем каталоге, но которые вы не хотите помещать под контроль версий. Примерами являются объектные файлы, получающиеся после компиляции. Обычно когда вы выполняете команду `cvs update', она выдает по строке на каждый файл, о котором не знает (see section Сообщения команды update).

CVS использует список файлов (или шаблонов файлов в стиле sh(1)), которые следует игнорировать при выполнении update, import и release. This list is constructed in the following way.

Список инициализируется определенными шаблонами имен файлов: имена, служащие для служебных целей CVS и других распространенных систем контроля версий; обычные имена файлов с заплатами, объектных и архивных файлов, а также резервных копий файлов, создаваемых текстовыми редакторами. Остальные имена -- побочные продукты деятельности разнообразных утилит. В настоящее время стандартный список шаблонов игнорируемых файлов таков:
```
RCS     SCCS    CVS     CVS.adm
    RCSLOG  cvslog.*
    tags    TAGS
    .make.state     .nse_depinfo
    *~      #*      .#*     ,*      _$*     *$
    *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
    *.a     *.olb   *.o     *.obj   *.so    *.exe
    *.Z     *.elc   *.ln
    core
```
Список игнорируемых файлов для каждого репозитория находится в `$CVSROOT/CVSROOT/cvsignore' и добавляется к общему списку, если этот файл существует.
Список игнорируемых файлов для каждого пользователя находится в домашнем каталоге пользователя в файле `~/.cvsignore' и добавляется к общему списку, если этот файл существует.
Содержимое переменной окружения $CVSIGNORE добавляется к списку.
Параметры ключей `-I' добавляются к списку.
Когда CVS обходит дерево каталогов, к списку добавляется содержимое файлов `.cvsignore'. Шаблоны, находящиеся в файле `.cvsignore', используются только в соответствующем каталоге, но не в его подкаталогах.

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

Задание команде cvs import ключа `-I !' приведет к импорту всего, и обычно вы именно этого и хотите, когда импортируете дистрибутив исходных текстов, не содержащий ничего лишнего. Однако, глядя на вышеприведенные правила, можно заметить ложку дегтя в бочке меда: если в дистрибутиве находятся файлы `.cvsignore', то они будут обработаны, даже если в командной строке был указан `-I !'. Для того, чтобы импортировать абсолютно все файлы, единственным обходным маневром будет удалить файлы `.cvsignore'. Это уродливо, поэтому в будущем `-I !' может перестать обрабатывать файлы `.cvsignore'.

Заметьте, что синтаксис файла со списком игнорируемых файлов состоит из набора строк, каждая из которых содержит список файлов, разделенных пробелами. Таким образом, нет простого способа задать имена файлов, содержащие пробелы, но можно использовать шаблон `foo?bar', чтобы игнорировать файл `foo bar' (в этом случае, правда, будет также проигнорирован файл `fooxbar' и т. п._). Заметьте, также, что сейчас не существует способа поместить в этот файл комментарии.

Файл history

Файл `$CVSROOT/CVSROOT/history' используется для журналирования информации для команды history (see section Команда history: показать состояние файлов и пользователей). Для того, чтобы включить журналирование, этот файл следует создать. Это происходит автоматически при выполнении команды cvs init, которая используется для инициализации репозитория (see section Создание репозитория).

Формат файла `history' документирован только в комментариях в исходном тексте CVS, но, в любом случае, обычно программы должны использовать команду cvs history, на тот случай, если формат изменится в следующих версиях CVS.

Подстановки в административных файлах

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

Для того, чтобы узнать домашний каталог пользователя, который запустил CVS (эта информация хранится в переменной окружения HOME), используйте `~', за которым следует `/' или конец строки. Точно так же, для получения домашнего каталога пользователя используйте `~user'. Подстановка этих переменных происходит на серверной машине, и поэтому такая подстановка не работает, если используется pserver (see section Прямое соединение с парольной аутентификацией). Для того, чтобы изменить поведение для каждого пользователя, лучше использовать пользовательские переменные (см. ниже).

Иногда требуется узнать различную информацию, используемую CVS. Внутренняя переменная CVS имеет такой синтаксис: ${переменная}, где переменная начинается с буквы и состоит из алфавитно-цифровых символов и символа подчерка (`_'). Если символ, который следует за variable, не является буквой, цифрой или знаком подчерка, то фигурные скобки можно опустить. Внутренние переменные CVS таковы:

CVSROOT: Здесь хранится корневой каталог используемого репозитория. See section Репозиторий, где описаны различные способы задания корневого каталога.
RCSBIN: В @cvsver{1.9.18} и раньше в этой переменной находился каталог, в котором находились программы RCS. Так как теперь CVS более не запускает RCS, использование этой внутренней переменной запрещено.
CVSEDITOR
VISUAL
EDITOR: Эти три переменных содержат одно и то же значение -- используемый текстовый редактор. See section Глобальные ключи командной строки, где описано, как задать этот редактор.
USER: Имя пользователя, запустившего CVS (на серверной машине).

Если вы хотите, чтобы пользователь мог задать какое-то значение, передающееся в административный файл, используйте пользовательскую переменную. Для подстановки такой переменной в административном файле написано ${=variable}. Для того, чтобы установить пользовательскую переменную, задайте CVS глобальный флаг `-s' с аргументом переменная=значение. Особенно полезно будет задать такой флаг в файле `~/.cvsrc' (see section Ключи по умолчанию и файл ~/.cvsrc).

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

cvs -s TESTDIR=/work/local/tests

и при административном файле, содержащем sh ${=TESTDIR}/runtests, то эта строка преобразуется в sh /work/local/tests/runtests.

Все другие строки, содержащие `$', зарезервированы; нет способа экранировать символ `$', чтобы он обозначал сам себя.

Файл конфигурации CVSROOT/config

Административный файл `config' содержит различные настройки, влияющие на поведение CVS. Синтаксис этого файла слегка отличается от синтаксиса прочих файлов. Переменные не подставляются. Строки, начинающиеся с `#', считаются комментариями.

Все прочие строки состоят из ключевого слова, символа `=' и значения. Заметьте, что этот синтаксис очень строг. Дополнительные пробелы и символы табуляции не допускаются.

В настоящий момент определены следующие ключевые слова:

RCSBIN=bindir: Для CVS версий от 1.9.12 до 1.9.18, это ключевое слово указывало, что следует искать программы RCS в каталоге bindir. Современные версии CVS не требуют программ RCS; для совместимости эта установка допускается, но ничего не делает.
SystemAuth=value: Если value равно `yes', то pserver должен искать пользователя в системной базе данных пользователей, если он не найден в `CVSROOT/passwd'. Если же значение равно `no', то все пользователи сервера с парольной аутентификацией должны существовать в `CVSROOT/passwd'. По умолчанию значение равно `yes'. Дополнительная информация о pserver находится в section Прямое соединение с парольной аутентификацией.
PreservePermissions=value: Включить поддержку для хранения в репозитории специальных файлов устройств, символических ссылок, прав доступа к файлами и информации об их владельцах. Значение по умолчанию: `no'. See section Специальные файлы, где описаны подробности использования этого ключевого слова.
TopLevelAdmin=value: Изменить поведение команды `checkout' так, чтобы она создавала каталог `CVS/' на уровень выше вашего рабочего каталога, вдобавок к каталогам `CVS/', которые создаются внутри извлеченных каталогов. Значение по умолчанию -- `no'. Эта опция полезна, если вы обнаружите, что выполняете многие команды в каталоге на уровень выше вашего рабочий каталога, а не в одном из извлеченных подкаталогов. Каталог `CVS/', созданный таким образом, позволяет не указывать `CVSROOT' при каждой команде. Обеспечивается также место для файла `CVS/Template' (see section Как данные хранятся в рабочем каталоге).
LockDir=directory: Создавать файлы блокировок CVS в каталоге directory, а не в репозитории. Это полезно, если вы хотите разрешить пользователям читать из репозитория, предоставив им доступ на запись только в directory, а не в репозиторий. Вам нужно создать directory, а CVS сама создаст там требуемые подкаталоги. Информация о блокировках CVS находится в главе section Совместный доступ нескольких разработчиков к CVS. Перед включением опции `LockDir' убедитесь, что вы не используете ни одной копии CVS версий 1.9 или раньше, которые не поддерживают `LockDir', и не дадут об этом никакого предупреждения. Если позволить такому случиться, то некоторые пользователи CVS будут делать блокировки в одном каталоге, а другие -- в другом, и репозиторий может быть испорчен. @cvsver{1.10} не поддерживает `LockDir', но выдаст предупреждение, если использовать его на репозитории с включенным `LockDir'.

Далее >>>