Пометки довольно запутанно взаимодействуют с операциями добавления и удаления файлов; в основном CVS отслеживает, существует файл или нет, не особенно беспокоясь о пустяках. По умолчанию, помечаются только файлы, которые имеют ревизии, соответствующие тому, что помечается. Файлы, которые еще не существуют или которые уже были удалены, просто пропускаются при пометке, при этом CVS знает, что отсутствие метки означает, что файл не существует в помеченном месте.
Однако, при этом можно потерять небольшое количество информации. Например, предположим, что файл был добавлен, а затем удален. Затем, если для этого файла отсутствует метка, нет способа сказать, потому ли это, что метка соответствует времени перед тем, как файл был добавлен, или после того, как он был удален. Если вы выполните cvs rtag с ключом командной строки -r, то CVS помечает файлы, которые были удалены, избегая таким образом проблемы. Например, можно указать -r HEAD, чтобы пометить головную ревизию.
Команда cvs rtag имеет ключ командной строки -a, очищающий метку с удаленных файлов, которые в противном случае не были бы помечены. Например, можно указать этот ключ вместе с -F при перемещении метки. Если переместить метку без -a, то метка на удаленных файлах все еще ссылалась бы на старую ревизию и не отражала бы того факта, что файл был удален. Я не считаю, что это обязательно, если указано -r, как отмечено выше.
Иногда ревизия, находящаяся в рабочем каталоге, содержит также дополнительную информацию о себе: например, она может находиться на ветке (см. раздел Глава 8. Создание и слияние ветвей), или же может быть ограничена с помощью checkout -D или update -D версиями, созданными ранее указанной даты. Так как эта информация долговременно сохраняется, то есть действует на последующие команды над рабочей копией, то мы называем ее липкой.
В большинстве случаев липкость — это запутанный аспект CVS, о котором вам не следует думать. Однако, даже если вы не желаете использовать эту возможность, вы все же захотите что-нибудь узнать о липких метках (например, как их избежать!).
Можно использовать команду status, чтобы посмотреть, какие установлены липкие метки или даты:
$ cvs status driver.c
===================================================================
File: driver.c Status: Up-to-date
Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag: rel-1-0-patches (branch: 1.7.2)
Sticky Date: (none)
Sticky Options: (none)
Липкие метки остаются на ваших рабочих файлах до тех пор, пока вы не удалите их с помощью cvs update -A. Опция -A извлекает версию файла из головной ревизии ствола и забывает обо всех липких метках, датах и ключах командной строки.
Самое распространенное использование липких меток — указать, над какой ветвью идет работа, что описано в разделе “Доступ к веткам”. Однако, липкие метки также используются и без веток. Предположим, например, что вы хотите избежать обновления вашего рабочего каталога, чтобы защититься от изменений, которые делают ваши коллеги. Вы, конечно, можете просто не выполнять команду cvs update. Если же вы хотите избежать обновления только части большого дерева, то липкие метки могут помочь. Если вы извлечете определенную ревизию, скажем, 1.4, то она станет липкой. Последующие команды cvs update не станут извлекать последнюю ревизию до тех пор, пока вы не очистите метку с помощью cvs update -A. Точно так же, использование ключа командной строки -D команд update и checkout задает липкую дату, которая используется для будущих извлечений.
Люди часто хотят извлечь старую версию файла без установки липкой метки. Это можно сделать с помощью ключа командной строки -p команд checkout или update, которая посылает содержимое файла на стандартный вывод. Например:
$ cvs update -p -r 1.1 file1 >file1 =================================================================== Checking out file1 RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v VERS: 1.1 *************** $
Однако, это не самый простой способ, если вы спрашиваете, как отменить последнее фиксирование (в этом примере — поместить file1 обратно в то состояние, в котором он был в ревизии 1.1). В этом случае лучше будет использовать ключ командной строки -j команды update; дальнейшее обсуждение находится в разделt “Слияние изменений между двумя ревизиями”.