подстановка ключевых слов

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

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

список ключевых слов

вот список ключевых слов:

$author$

имя пользователя, который поместил ревизию в репозиторий.

$date$

дата и время (в utc), когда была зафиксирована ревизия.

$header$

стандартный заголовок, содержащий полное имя rcs-файла, номер ревизии, дату в utc, имя автора, состояние и имя пользователя, заблокировавшего этот файл (если файл заблокирован). файлы обычно не блокируются при использовании cvs.

$id$

точно так же, как $header$, только имя rcs-файла указано без полного пути.

$name$

имя метки, использованной при извлечении этого файла. это ключевое слово подставляется, только если при извлечении было явно задано имя метки. например, при выполнении команды cvs co -r first это ключевое слово заменяется на `name: first'.

$locker$

имя пользователя, который заблокировал эту ревизию (пустое, если файл не заблокирован, как обычно и бывает, если не использовалась команда cvs admin -l).

$log$

журнальное сообщение, которое было введено во время фиксации изменений, перед которым идет имя rcs-файла, номер ревизии, имя автора и дата в utc. существующие журнальные сообшения не заменяются. вместо этого, новое журнальное сообщение добавляется после $log:...$. каждая новая строка содержит в начале ту же самую строку, которая находится перед ключевым словом $log$. например, если в файле находится

  /* here is what people have been up to:
   *
   * $log: frob.c,v $
   * revision 1.1  1997/01/03 14:23:51  joe
   * add the superfrobnicate option
   *
   */

то перед дополнительными строками, которые добавляются при замене ключевого слова $log$, будет находиться ` * '. в отличие от предыдущих версий cvs и rcs, префикс комментария из rcs-файла не используется. ключевое слово $log$ полезно при накоплении полного журнала изменений в исходном файле, но по нескольким причинам это может привести к определенным проблемам. see section проблемы с ключевым словом $log$..

$rcsfile$

имя rcs-файла без полного пути.

$revision$

номер ревизии.

$source$

полное имя rcs-файла.

$state$

состояние, присвоенное ревизии. состояния могут назначаться с помощью cvs admin -s -- см. section ключи команды admin.

использование ключевых слов

для того, чтобы поместить в файл ключевое слово, вы просто пишете в нём, например, $id$, а затем фиксируете файл. cvs автоматически заменит ключевое слово во время операции фиксирования.

обычной практикой является помещение строки $id$ в исходные файлы, чтобы они оказались в скомпилированных объектных файлах. например, если вы управляете исходными текстами программы, вы можете создать переменную, в которую при инициализации попадает строка с $id$. некоторые компиляторы языка c поддерживают директиву #pragma ident. система управления документами может обеспечивать способ для передачи этой строки в результирующие файлы.

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

$ ident samp.c
samp.c:
     $id: samp.c,v 1.5 1993/10/19 14:57:32 ceder exp $
$ gcc samp.c
$ ident a.out
a.out:
     $id: samp.c,v 1.5 1993/10/19 14:57:32 ceder exp $

sccs -- еще одна популярная система контроля ревизий. в её состав входит программа what, очень похожая на ident и использующаяся в тех же целях. во многих местах, где не установлен пакет rcs, стоит sccs. так как what ищет последовательность символов @(#), то можно довольно просто вставлять ключевые слова, которые обнаруживаются обеими программами. просто поместите перед ключевым словом в стиле rcs волшебную фразу в стиле sccs, например:

static char *id="@(#) $id: ab.c,v 1.5 1993/10/19 14:57:32 ceder exp $";

как избежать подстановки

подстановка ключевых слов имеет свои недостатки. иногда бывает нужно, чтобы строка `$'author$ появилась в файле без того, чтобы cvs интерпретировала её как ключевое слово и заменила на что-нибудь типа `$'author: ceder $.

к сожалению, нельзя выборочно отключить подстановку ключевых слов. можно лишь использовать ключ командной строки `-ko' (see section режимы подстановки), чтобы полностью выключить эту подстановку.

во многих случаях вам нужно избежать использования ключевых слов в исходном тексте, даже несмотря на то, что они появятся в конечном продукте. например, исходный текст этого руководства содержит `$@asis{}author$' везде, где должна появиться строка `$'author$. при использовании nroff и troff можно поместить в ключевое слово нулевой символ \&, чтобы добиться подобного эффекта.

режимы подстановки

вместе с каждым файлом хранится его режим подстановки ключевых слов по умолчанию, и каждая копия файла в рабочем каталоге также имеет режим подстановки. режим по умолчанию задается с помощью ключа `-k' команд cvs add и cvs admin; режим в рабочем каталоге задается с помощью ключей `-k' и `-a' команд cvs checkout и cvs update. команда cvs diff также имеет ключ `-k'. некоторые примеры приведены в section обработка двоичных файлов.

доступные режимы таковы:

`-kkv'

генерировать строки из ключевых слов стандартным образом, то есть из ключевого слова revision получается $revision: 5.7 $.

`-kkvl'

подобно `-kkv', но только всегда указывается имя заблокировавшего пользователя, если данная ревизия в настоящий момент заблокирована. имя блокировщика имеет смысл только если используется cvs admin -l.

`-kk'

генерировать только имена ключевых слов и опускать их значения. например, для ключевого слова revision получается строка $revision$, а не $revision: 5.7 $. этот ключ полезен для игнорирования изменений, возникающих из-за ключевых слов, при сравнении разных ревизий файла.

`-ko'

генерирует старую строку, присутствовавшую в рабочем файле перед тем, как он был зафиксирован. например, для ключевого слова revision генерируется строка $revision: 1.1 $ вместо $revision: 5.7 $, если она была записана именно так, когда файл был помещен в репозиторий.

`-kb'

подобно `-ko', но также предотвращает преобразование символов конца строк между канонической формой, в которой они хранятся в репозитории (только символ перевода строки), и формой, принятой в используемой операционной системе. для unix-подобных систем, в которых для завершения строк используется символ перевода строки, этот режим совпадает с `-ko'. дополнительная информация о двоичных файлах находится в section обработка двоичных файлов.

`-kv'

генерирует только значения ключевых строк. например, для ключевого слова revision генерируется строка 5.7 вместо $revision: 5.7 $. это может помочь при генерации файлов на языках программирования, в которых сложно извлечь из строки разделители ключевых слов, такие как как $revision: $. однако, дальнейшая подстановка ключевых слов не может быть осуществлена, когда удалены ключевые слова, поэтому этот ключ нужно использовать осторожно. часто бывает полезно использовать `-kv' совместно с командой cvs export -- see section команда export: экспортировать исходные тексты. помните только, что этот ключ некорректно экспортирует двоичные файлы.

проблемы с ключевым словом $log$.

ключевое слово $log$ довольно-таки спорно. пока вы работаете над проектом, информация легко доступна даже без использования ключевого слова $log$: просто вызовите cvs log. когда вы экспортируете файл, информация об его истории в любом случае практически бесполезна.

более серьёзным обстоятельством является то, что cvs не слишком хорошо справляется с пунктами $log$, когда ветка объединяется с основным стволом. в результате такого объединения часто возникают конфликты.

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

звучали рекомендации помещать ключевое слово $log$ в конец файла (если вообще нужно использовать это слово). в этом случае длинный список сообщений об изменениях не будет мешать чтению исходного файла.

go to the first, previous, next, last section, table of contents.