В репозитории CVS в каталоге `$CVSROOT/CVSROOT/' находится несколько вспомогательных файлов. При работе с CVS эти файлы можно и не использовать, но, будучи правильно настроенными, они способны сильно облегчить вам жизнь. Методика редактирования таких файлов обсуждается в section Справочник по административным файлам.
Самым важным таким файлом является `modules', которые описывает модули, находящиеся в репозитории.
В файле `modules' находится описание модулей, то есть коллекций исходных текстов. Файл модулей можно редактировать обычным для административных файлов способом.
Файл `modules' может содержать пустые строки и комментарии (строки, начинающиеся с `#'), а также описания модулей. Длинные описания можно разбивать на несколько строк, используя обратную косую черту (`\') в качестве последнего символа в строке.
Существует три основных типа модулей: модули-синонимы, обычные модули и амперсенд-модули. Разница между ними заключается в способе сопоставления файлов в репозитории файлам в рабочем каталоге. В нижеприведенных примерах в репозитории находится каталог `first-dir/', содержащий два файла, `file1' и `file2', а также каталог `sdir/'. `first-dir/sdir/' содержит также файл `sfile'.
Модули синонимы -- это самый простой вид модулей:
mname -a aliases...
Например, если файл `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... ]
$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
-i prog
-o prog
-s status
-t prog
rtag. prog
выполняется с двумя аргументами: именем модуля и именем метки,
указанной в команде rtag. Эта программа не
выполняется, когда дается команда tag. Обычно лучше
использовать файл `taginfo' (see section Настройка журналирования).
-u prog
Обертки -- это возможность CVS, позволяющая управлять определенными настройками, основываясь на имени обрабатываемого файла. В список таких настроке входят ключи `-k' для двоичных файлов и `-m' для файлов, которые нельзя автоматически объединять.
Ключ `-m' задает метод объединения, который нужно
использовать при обновлении не-двоичного файла. `MERGE'
означает обычное поведение CVS: попробовать объединить
файлы. `COPY' означает, что cvs update откажется
объединять файлы, точно так же, как это происходит с двоичными
файлами, описанными с помощью ключа `-kb' (если файл описан
как двоичный, то использовать `-m 'COPY'' необязательно).
CVS предоставит пользователю две версии файлов, и потребует
вручную внести необходимые изменения, пользуясь внешними по
отношению к CVS инструментами. Предупреждение: не
используйте `COPY' с CVS версии 1.9 и раньше -- они
просто перезапишут один файл поверх другого, уничтожая старое
содержимое.
Ключ `-m' влияет только на поведение при обновлении, не
затрагивая способ хранения файла. См. section Обработка двоичных файлов, где
описана работа с ними.
В основном формат файла `cvswrappers' таков:
маска_файла [ключ значение][ключ значение]...
где ключ -- это
-m
-k
а значение заключено в одиночные кавычки.
Например, нижеследующая команда импортирует каталог, считая
файлы, заканчивающиеся на `.exe', двоичными:
cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
Флаг `-i' в файле `modules' может использоваться для выполнения определенной программы, когда соответствующие файлы помещаются в репозиторий (see section Файл `modules'). Файлы, описанные в этой секции, обеспечивают другие, более гибкие способы выполнения программ при фиксировании.
Есть три вида программ, которые можно выполнять при фиксировании. Они указываются в файлах в репозитории, как описано ниже. В этой таблице находится сводка таких файлов и назначение соответствующих программ:
Административные файлы, такие как `commitinfo', `loginfo', `rcsinfo', `verifymsg', и т. д., все имеют общий формат. Назначение этих файлов описано позднее, а здесь описан их общий синтаксис.
Каждая строка содержит следующее:
Пустые строки игнориуются. Строки, которые начинаются с символа `#', считаются комментариями. Длинные строки, к сожалению, не могут быть разбиты на части.
Используется первое регулярное выражение, которое совпадает с именем текущего каталога в репозитории. Остаток строки используется, соответственно, как имя файла или командная строка.
Файл `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' устарело. Для
задания редактора журнальных записей по умолчанию используйте
переменную окружения 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',
вместе с соответствующим шаблоном журнального сообщения в файле
`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' используется для управления тем, куда
посылается журнальная информация при выполнении `cvs
commit'. В левой части строки находится регулярное выражение, с
которым совпадает имя каталога, в котором производится изменение,
относительно $CVSROOT. Остаток соответствующей строки --
это программа-фильтр, которая получает журнальное сообщение на
стандартный ввод.
Если имя в репозитории не совпадает ни с одним регулярным выражением, используется строка `DEFAULT', если она есть.
Все строки, начинающиеся с `ALL', используются вдобавок к обычным строкам с совпадающим регулярным выражением, и со строкой `DEFAULT'.
Используется первое совпадающее регулярное выражение.
See section Выполнение программ на разных стадиях фиксирования, где описан синтаксис файла `loginfo'.
Пользователь может использовать в имени команды форматные строки. Такие строки состоят из символа `%', за которым следует пробел, одиночный форматный символ или набор форматных символов, заключенных в скобки `{' и `}'. Форматные символы таковы:
Все прочие символы, появляющиеся в форматной строке, превращаются в пустые строки (запятые, разделяющие их, сохраняются).
Например, можно использовать форматные строки `%', `%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' с помощью крохотного скрипта
добавляет журнальные сообщения к файлу
`$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' имеет синтаксис, подобный синтаксису файлов `verifymsg', `commitinfo' и `loginfo'. See section Обычный синтаксис. В отличие от остальных файлов, правая часть строки является не шаблоном команды, но полным именем файла, содержащего шаблон журнального сообщения.
Если имя в репозитории не соответствует ни одному регулярному выражению в этом файле, используется строка `DEFAULT', если она есть.
Все строки, начинающиеся с `ALL', используются вдобавок к первому совпадающему регулярному выражению или строке `DEFAULT'.
Шаблон журнального сообщения будет использоваться по умолчанию. Если вы зададите журнальное сообщение с помощью `cvs commit -m message' или `cvs commit -f file', то вместо шаблона будет использоватсья именно оно.
See section Проверка журнальных записей, где приведен пример файла `rcsinfo'.
Когда CVS обращается к сетевому репозиторию, используется то содержимое файла `rcsinfo', которое было, когда каталог был извлечен в последний раз. Если вы редактируете `rcsinfo' или шаблоны, которые используются в нем, вам потребуется заново извлечь рабочий каталог.
Есть определенные имена файлов, которые постоянно находятся в вашем рабочем каталоге, но которые вы не хотите помещать под контроль версий. Примерами являются объектные файлы, получающиеся после компиляции. Обычно когда вы выполняете команду `cvs update', она выдает по строке на каждый файл, о котором не знает (see section Сообщения команды update).
CVS использует список файлов (или шаблонов файлов в стиле
sh(1)), которые следует игнорировать при выполнении
update, import и release.
This list is constructed in the following way.
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
$CVSIGNORE добавляется к
списку.
Во всех перечисленных местах использование восклицательного знака (`!') очищает список. Это можно использовать для хранения файлов, которые обычно игнорируются CVS.
Задание команде cvs import ключа `-I !' приведет к
импорту всего, и обычно вы именно этого и хотите, когда
импортируете дистрибутив исходных текстов, не содержащий ничего
лишнего. Однако, глядя на вышеприведенные правила, можно
заметить ложку дегтя в бочке меда: если в дистрибутиве находятся
файлы `.cvsignore', то они будут обработаны, даже если в
командной строке был указан `-I !'. Для того, чтобы
импортировать абсолютно все файлы, единственным обходным маневром
будет удалить файлы `.cvsignore'. Это уродливо, поэтому в
будущем `-I !' может перестать обрабатывать файлы
`.cvsignore'.
Заметьте, что синтаксис файла со списком игнорируемых файлов состоит из набора строк, каждая из которых содержит список файлов, разделенных пробелами. Таким образом, нет простого способа задать имена файлов, содержащие пробелы, но можно использовать шаблон `foo?bar', чтобы игнорировать файл `foo bar' (в этом случае, правда, будет также проигнорирован файл `fooxbar' и т. п._). Заметьте, также, что сейчас не существует способа поместить в этот файл комментарии.
Файл `$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
RCSBIN
CVSEDITOR
VISUAL
EDITOR
USER
Если вы хотите, чтобы пользователь мог задать какое-то значение,
передающееся в административный файл, используйте
пользовательскую переменную. Для подстановки такой переменной в
административном файле написано ${=variable}. Для
того, чтобы установить пользовательскую переменную, задайте
CVS глобальный флаг `-s' с аргументом
переменная=значение. Особенно полезно будет
задать такой флаг в файле `~/.cvsrc' (see section Ключи по умолчанию и файл ~/.cvsrc).
Например, если вы хотите, чтобы административный файл ссылался на
тестовый каталог, вы можете создать пользовательскую переменную
TESTDIR. Затем, если запустить CVS как
cvs -s TESTDIR=/work/local/tests
и при административном файле, содержащем sh
${=TESTDIR}/runtests, то эта строка преобразуется в sh
/work/local/tests/runtests.
Все другие строки, содержащие `$', зарезервированы; нет способа экранировать символ `$', чтобы он обозначал сам себя.
Административный файл `config' содержит различные настройки, влияющие на поведение CVS. Синтаксис этого файла слегка отличается от синтаксиса прочих файлов. Переменные не подстанавливаются. Строки, начинающиеся с `#', считаются комментариями.
Все прочие строки состоят из ключевого слова, символа `=' и значения. Заметьте, что этот синтаксис очень строг. Дополнительные пробелы и символы табуляции не допускаются.
В настоящий момент определены следующие ключевые слова:
RCSBIN=bindir
SystemAuth=value
PreservePermissions=value
TopLevelAdmin=value
LockDir=directory
Go to the first, previous, next, last section, table of contents.