|
go to the first, previous, next, last section, table of contents.
справочник по административным файламв репозитории cvs в каталоге `$cvsroot/cvsroot/' находится несколько вспомогательных файлов. при работе с cvs эти файлы можно и не использовать, но, будучи правильно настроенными, они способны сильно облегчить вам жизнь. методика редактирования таких файлов обсуждается в section справочник по административным файлам. самым важным таким файлом является `modules', которые описывает модули, находящиеся в репозитории. файл `modules'в файле `modules' находится описание модулей, то есть коллекций исходных текстов. файл модулей можно редактировать обычным для административных файлов способом. файл `modules' может содержать пустые строки и комментарии (строки, начинающиеся с `#'), а также описания модулей. длинные описания можно разбивать на несколько строк, используя обратную косую черту (`\') в качестве последнего символа в строке. существует три основных типа модулей: модули-синонимы, обычные модули и амперсенд-модули. разница между ними заключается в способе сопоставления файлов в репозитории файлам в рабочем каталоге. в нижеприведенных примерах в репозитории находится каталог `first-dir/', содержащий два файла, `file1' и `file2', а также каталог `sdir/'. `first-dir/sdir/' содержит также файл `sfile'. модули-синонимымодули синонимы -- это самый простой вид модулей:
например, если файл `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 обычные модули
например, если модуль описан как 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'. флаги модулейописание обычных и амперсенд-модулей может содержать флаги, предоставляющие дополнительную информацию о модуле.
файл `cvswrappers'обертки -- это возможность cvs, позволяющая управлять определенными настройками, основываясь на имени обрабатываемого файла. в список таких настроек входят ключи `-k' для двоичных файлов и `-m' для файлов, которые нельзя автоматически объединять.
ключ `-m' задает метод объединения, который нужно
использовать при обновлении не-двоичного файла. `merge'
означает обычное поведение cvs: попробовать объединить
файлы. `copy' означает, что в основном формат файла `cvswrappers' таков: маска_файла [ключ значение][ключ значение]... где ключ -- это
а значение заключено в одиночные кавычки. например, нижеследующая команда импортирует каталог, считая файлы, заканчивающиеся на `.exe', двоичными: cvs import -i ! -w "*.exe -k 'b'" first-dir vendortag reltag выполнение программ на разных стадиях фиксированияфлаг `-i' в файле `modules' может использоваться для выполнения определенной программы, когда соответствующие файлы помещаются в репозиторий (see section файл `modules'). файлы, описанные в этой секции, обеспечивают другие, более гибкие способы выполнения программ при фиксировании. есть три вида программ, которые можно выполнять при фиксировании. они указываются в файлах в репозитории, как описано ниже. в этой таблице находится сводка таких файлов и назначение соответствующих программ:
обычный синтаксисадминистративные файлы, такие как `commitinfo', `loginfo', `rcsinfo', `verifymsg', и т. д., все имеют общий формат. назначение этих файлов описано позднее, а здесь описан их общий синтаксис. каждая строка содержит следующее:
пустые строки игнорируются. строки, которые начинаются с символа `#', считаются комментариями. длинные строки, к сожалению, не могут быть разбиты на части. используется первое регулярное выражение, которое совпадает с именем текущего каталога в репозитории. остаток строки используется, соответственно, как имя файла или командная строка. файл `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' устарело. для
задания редактора журнальных записей по умолчанию используйте
переменную окружения если вы хотите убедиться, что все журнальные сообщения выглядят одинаково, то можете использовать файл `editinfo', чтобы задать программу, используемую для редактирования этих сообщений. этой программой может быть текстовый редактор, настроенный специальным образом, или небольшой скрипт, который вызывает редактор и проверяет, что введенное сообщение содержит все требуемые поля.
если в файле `editinfo' не найдено совпадающей строки,
используется редактор, заданный переменной окружения
файл `editinfo' наиболее полезно использовать вместе с файлом `rcsinfo', который используется в качестве шаблона журнального сообщения. каждая строка в файле `editinfo' состоит из регулярного выражения и шаблона команды, состоящего из имени программы и, возможно, нескольких аргументов. к шаблону программы добавляется полное имя текущего шаблона журнального сообщения. следует заметить, что ключевое слово `all' не поддерживается. если совпадает более одной строки, используется первая. это полезно для задания скрипта редактирования по умолчанию, а затем переопределения его в подкаталоге. если имя каталога в репозитории не совпадает ни с одним регулярным выражением в этом файле, то используется строка `default', если она есть. если скрипт редактирования завершается с ненулевым кодом завершения, то процесс фиксирования аварийно завершается.
заметьте, что когда cvs обращается к сетевому репозиторию,
или когда используются ключи `-m' и `-f' команды
пример использования 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'. в левой части строки находится регулярное выражение, с
которым совпадает имя каталога, в котором производится изменение,
относительно если имя в репозитории не совпадает ни с одним регулярным выражением, используется строка `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нижеследующий файл `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', который
будет вызывать ^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)), которые следует игнорировать при выполнении
во всех перечисленных местах использование восклицательного знака (`!') очищает список. это можно использовать для хранения файлов, которые обычно игнорируются cvs.
задание команде заметьте, что синтаксис файла со списком игнорируемых файлов состоит из набора строк, каждая из которых содержит список файлов, разделенных пробелами. таким образом, нет простого способа задать имена файлов, содержащие пробелы, но можно использовать шаблон `foo?bar', чтобы игнорировать файл `foo bar' (в этом случае, правда, будет также проигнорирован файл `fooxbar' и т. п._). заметьте, также, что сейчас не существует способа поместить в этот файл комментарии. файл history
файл `$cvsroot/cvsroot/history' используется для
журналирования информации для команды
формат файла `history' документирован только в комментариях
в исходном тексте cvs, но, в любом случае, обычно программы
должны использовать команду подстановки в административных файлахиногда, при написании административного файлы вы хотели бы, чтобы в этом файле можно было бы использовать информацию о среде, в которой выполняется cvs. есть несколько механизмов, с помощью которых можно этого добиться.
для того, чтобы узнать домашний каталог пользователя, который
запустил cvs (эта информация хранится в переменной окружения
иногда требуется узнать различную информацию, используемую
cvs. внутренняя переменная cvs имеет такой синтаксис:
если вы хотите, чтобы пользователь мог задать какое-то значение,
передающееся в административный файл, используйте
пользовательскую переменную. для подстановки такой переменной в
административном файле написано
например, если вы хотите, чтобы административный файл ссылался на
тестовый каталог, вы можете создать пользовательскую переменную
cvs -s testdir=/work/local/tests
и при административном файле, содержащем все другие строки, содержащие `$', зарезервированы; нет способа экранировать символ `$', чтобы он обозначал сам себя. файл конфигурации cvsroot/configадминистративный файл `config' содержит различные настройки, влияющие на поведение cvs. синтаксис этого файла слегка отличается от синтаксиса прочих файлов. переменные не подставляются. строки, начинающиеся с `#', считаются комментариями. все прочие строки состоят из ключевого слова, символа `=' и значения. заметьте, что этот синтаксис очень строг. дополнительные пробелы и символы табуляции не допускаются. в настоящий момент определены следующие ключевые слова:
go to the first, previous, next, last section, table of contents. |