• У каждого файла своя нумерация редакций. Поэтому нет единой нумерованной редакции для всего проекта.
• Номер редакция изменяется при обновлении файла в репозитории. Поэтому чем чаще изменяется файл, чем чаще выполняется операция commit - тем больше редакций будет у файла в репозитории.
• Номера редакций могут только возрастать.
• Для каждой редакции хранится множество дополнительной информации, в частности, когда она была помещена в репозиторий, кто это сделал (если метод доступа поддерживает имена пользователей), какой был комментарий и многое другое
Вы можете установить метку (tag), объединяющую редакции файлов, находящихся в рабочем каталоге. Например, можно установить имя для всех файлов в текущем состоянии репозитория после выпуска очередной версии своего продукта на рынок. Для этого используется команда tag:
› cvs tag release-1-0
cvs tag: Tagging.
T readme.txt
T test.c
T todo.txt
В отличие от команд add, remove и модификации файла, команда tag работает напрямую с репозиторием и присваивает метки редакциям файлов, которые находятся в настоящий момент в рабочем каталоге. Поскольку команда модифицирует репозиторий напрямую, она не принимает во внимание локальные изменения, которые Вы, возможно, внесли в файлы в рабочем каталоге. Можно заставить CVS проверить, что все файлы находятся в репозитории, добавив ключ -c к команде tag:
› cvs tag -c release-1-0
cvs tag: test.c is locally modified
cvs [tag aborted]: correct the above errors first!
›
WINCVS Создать метку позволяет команда Create a tag on selection… из меню Modify.
Для того, чтобы получить какую-то конкретную редакцию файла, уже ставшую историей, достаточно задать дополнительные параметры для команды update или checkout. Но прежде, чем описать эти параметры, необходимо остановиться на продолжительности действия их результатов. Многие параметры сохраняют в рабочем каталоге так называемые липкие метки. Липкие метки сохраняют свое действие для всех последующих команд, даже если соответствующие параметры не указаны. Они необходимы, когда требуется ограничить обновление определённой части проекта. Например, в отдельном каталоге может находиться библиотека, разрабатываемая другой командой, и вас интересуют только её стабильные версии. Каждый раз, когда появляется следующая стабильная версия библиотеки, её разработчики создают новую метку, и вы обновляете рабочий каталог с указанием этой метки. Дальнейшие модификации не будут попадать в рабочий каталог до следующей стабильной версии.
Такие метки нужно сбрасывать явно, если их действие больше не требуется. Для их сброса используется ключ -A команды update
› cvs update -A
WINCVS В этой оболочке нет специальных команд для выполнения таких операций. Вместо этого используется закладка sticky options в диалоге Update. Чтобы сбросить липкие метки, используйте галочку “Reset any sticky date/tag/-k options” в том же диалоге
Такая команда сбросит все прилипшие метки и получит самую свежую копию из репозитория для всех файлов в текущем каталоге (рекурсивно для подкаталогов). Получить текущее состояние липких меток можно командой status.
> cvs status
cvs status: Examining .
===================================================================
File: readme.txt Status: Up-to-date
Working revision: 1.1 Mon Dec 9 13:27:28 2002
Repository revision: 1.1 d:\temp\rep/test/readme.txt,v
Sticky Tag: 1.1
Sticky Date: (none)
Sticky Options: (none)
Теперь рассмотрим команды, которые помогут получить самые различные редакции файлов.
Чтобы получить конкретную редакцию по номеру или метке для отдельного файла, подкаталога или всего проекта, используется ключ -r для команды update, параметром к которому должен быть либо номер редакции, либо ранее присвоенная метка. Следующая команда приведёт рабочий каталог к состоянию, в котором эта метка была присвоена:
› cvs update -r release-1-0
А эта команда достанет из репозитория самую первую редакцию файла readme.txt - то состояние, в котором он был добавлен в репозиторий:
› cvs update -r 1.1 readme.txt
Параметр -r создаёт липкую метку для файлов. Если вы получили конкретную редакцию или набор файлов по метке, вы больше не будете получать обновлений, пока не сбросите липкие метки или кто-то их не передвинет.
ПРЕДУПРЕЖДЕНИЕ Использование номера редакции при обновлении каталога относительно бессмысленно. Редакции файлов независимы, поэтому команда cvs update -r 1.2 достанет из репозитория все файлы, которые вообще хоть раз обновлялись, и именно их вторую редакцию. Скорее всего, это будет несовместная сборка файлов из разных периодов жизни проекта, в том числе и уже удалённых. Пользуйтесь символическими метками (тегами) для установления логической связи между редакциями файлов.
Ключ -D поможет получить состояние исходных текстов по дате создания редакции. Выбирается самая последняя редакция, созданная не позже указанной даты. Например, можно получить вчерашние файлы, если вчера всё работало, а сегодня что-то сломалось. Можно просто посмотреть какой-то старый код, в котором была нужная сегодня функция.
› cvs update -D date_spec
Такое обновление также создаёт липкие метки на файлах - пока они их не сброшены, Вы не получите обновлений с датой позже указанной. Формат даты (date_spec) может быть очень разным, CVS поддерживает многое из спецификации ISO8601, но вам, скорее всего, понадобится всего несколько вариантов, которые я здесь приведу в качестве примера:
2002-12-06 // дата в формате YYYY-MM-DD
2002-12-06 18:22 // дата в формате YYYY-MM-DD HH:MM
6 Dec 2002 // дата в формате DD MMM YYYY
yesterday // вчера
1 hour ago // час назад
7 days ago // неделю назад
Заключение
В этой статье я попытался рассказать о базовых возможностях работы с CVS с тем, чтобы любой программист мог непосредственно начать использовать это мощное средство. Тем не менее, возможности CVS не ограничиваются описанными в этой статье. В следующей статье о CVS мы продолжим изучение этой системы.