Если кто-то захочет иметь список версий для более чем одного файла, то это проще сделать с использованием понятия тег (tag), который представляет собой символическое имя версии. Оно может быть присвоено числовому значению версии в каждом файле.
Для каждой версии файла имеется уникальный номер версии (revision number). Номер версии выглядит как 1.1, 1.2, 1.3.2.2 или даже 1.3.2.2.4.5. Номер версии всегда имеет ч©тное число целых чисел, раздел©нных точками. По умолчанию версия 1.1 является первой (или исходной) версией файла. Каждая последующая версия добавляет единицу в самую правую позицию номера версии. Нижеследующая картинка показывает последовательные версии:
+-----+ +-----+ +-----+ +-----+ +-----+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! +-----+ +-----+ +-----+ +-----+ +-----+
Имеются номера версий, содержащих более, чем одну точку, например как 1.3.2.2. Такие номера версий представляют версии ветвей, которые обсуждаются в разделе 14.7.
Когда вы добавляете новый файл, вторая цифра будет всегда 1, а первое число будет равно наибольшему первому числу в версии любого файла в данном каталоге. Например, если текущий каталог содержит файлы, чьи наиболее свежие версии имеют номера: 1.7, 3.1 и 4.12, тогда вновь добавляемому файлу будет присвоен номер версии 4.1.
Обычно нет нужды специально беспокоиться о номерах версий, система CVS сама наблюдает за ними и модифицирует, когда необходимо. Проще их
воспринимать как некоторые внутренние переменные CVS. Теги
(символьные имена версий) дают более удобный механизм для того, чтобы
отделить, например, версию 1 от версии 2 вашего продукта. Однако, если вы
хотели бы установить версии файлов в виде числовом выражении, то вы может
использовать команду
cvs commit -r 3.0
Здесь параметр -r подразумевает параметр -f в том смысле, что
все файлы будут отмечены в хранилище как обновл©нные независимо oт того,
имело ли место реальное изменение файлов.
При этом все файлы получат номер версии 3.0, если до выполнения данной
команды не было файлов с версией больше, чем 3.0. Таким образом, если ваши
файлы уже имеют версию 3.0, то вы не сможете присвоить им версию 1.3.
Если вы желаете поддерживать несколько параллельных версий вашего продукта (скажем, 1.x и 3.x), то следует использовать механизм ветвей.
Номера версий файлов живут своей собственной жизнью. Совсем необязательно, чтобы они как-то были связаны с версиями вашего продукта.
В зависимости от того, как вы используете CVS, версии отдельных файлов могут измениться несколько раз между двумя последовательными версиями вашего продукта. В качестве примера мы можем рассмотреть комплект исходных текстов системы RCS 5.6, которые имеют следующие номера версий:
ci.c 5.21
co.c 5.9
ident.c 5.3
rcs.c 5.12
rcsbase.h 5.11
rcsdiff.c 5.10
rcsedit.c 5.11
rcsfcmp.c 5.9
rcsgen.c 5.10
rcslex.c 5.11
rcsmap.c 5.2
rcsutil.c 5.10
Вы можете использовать команду tag, чтобы дать символическое имя (тег) определ©нной версии отдельного файла. Вы можете также использовать команду status с параметром -v, чтобы увидеть все теги, которые имеет данный файл, а также номер версии, которую обозначает данный тег.
Имена тегов должны начинаться с буквы в любом регистре и могут содержать любые буквы, цифры и только два специальных знака "-" (минус), "_" (подч©ркивание). Два тега с именами BASE и HEAD зарезервированы за системой CVS. При выполнении большого проекта полезно придерживаться определ©нных соглашений об используемых именах тегов. Например, если ваша система имеет имя TERCIYA, то имя тега TERCIYA-3_0 может представлять версию 3.0. Вы можете также использовать файл taginfo, чтобы описать соглашение об именах тегов.
Следующий пример показывает, как вы можете добавить тег к файлу. Команды добавления тега должны быть выданы внутри рабочего каталога, т.е. там, где находится рабочая копия вашего файла (модуля).
$ cvs tag rel-0-4 backend.c
T backend.c
$ cvs status -v backend.c
===================================================================
File: backend.c Status: Up-to-date
Version: 1.4 Tue Dec 1 14:39:01 1992
RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
rel-0-4 (revision: 1.4)
Здесь привед©н нечасто встречающийся пример, когда тегом помечается
единственный файл (модуль).
Обычно необходимо пометить определ©нным тегом все файлы, которые входят
в продукт или составляют вместе определ©нный программный модуль.
Это выполняется в те моменты, которые важны для всего проекта, например,
при выпуске очередной версии программного продукта.
$ cvs tag rel-1-0 .
cvs tag: Tagging .
T Makefile
T backend.c
T driver.c
T frontend.c
T parser.c
В примере тегом помечаются все модули рабочего каталога (заметим попутно,
что и все подкаталоги, если они есть). Если впоследствии, вы захотите
взять из хранилища лишь те файлы, которые относятся к версии продукта
rel-1-0, то это выполняется командой
cvs checkout -r rel-1-0 tc
что, естественно, чрезвычайно удобно.
Когда тегом отмечаются несколько файлов, то это можно изобразить
графически двояким образом. Например:
file1 file2 file3 file4 file5
1.1 1.1 1.1 1.1 /--1.1* <-*- Тег
1.2*- 1.2 1.2 -1.2*-
1.3 \- 1.3*- 1.3 / 1.3
1.4 \ 1.4 / 1.4
\-1.5*- 1.5
1.6
Здесь видно, что одни файлы меняются со временем чаще, другие - реже. В
какой-то момент времени мы отметили их тегом (зв©здочки). Таким образом,
мы сможем вызвать эти версии файлов в любой момент, когда нам это
понадобится.
То же самое можно нарисовать иначе.
file1 file2 file3 file4 file5
1.1
1.2
1.1 1.3 _
1.1 1.2 1.4 1.1 /
1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Смотреть здесь
1.3 1.6 1.3 \_
1.4 1.4
1.5
Иногда рабочая копия комплекта исходных текстов имеет дополнительную информацию, например, такое может быть, когда вы работаете с ветвью или рабочая копия ограничена версиями определ©нной даты командами 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)
Липкие теги останутся в ваших рабочих файлах до того момента, пока вы не
удалите их с помощью команды
Наиболее общеупотребительное использование липких тегов состоит в идентификации того, какая ветвь является рабочей в данный момент. Однако, липкие теги используются и вне контекста ветвей. Например, вы хотите избежать обновления (команда update) вашего рабочего каталога, чтобы изолировать себя на время от дестабилизирущих частых изменений со стороны других разработчиков. Конечно, вы можете просто воздержаться от выполнения команды update. Однако вы хотели бы не обновлять лишь группу файлов из большого дерева каталогов. В этом случае может помочь липкий тег. Если вы выполните команду cvs checkout для определ©нной версии, например, 1.4, рабочая копия файлов станет липкой. Последующие команды cvs update не будут разыскивать последние версии файлов в хранилище для файлов, которые находятся в вашем рабочем каталоге до того момента пока вы не выполните cvs update -A, очистив липкий тег.
Таким же образом, использование параметра -D в командах checkout и update устанавливает липкую дату, которая подобным же образом будет использоваться в последующих командах CVS.
Часто вы захотите найти старую версию файла без установки липкого тега.
Способ состоит в том, чтобы использовать параметр -p в командах checkout или update, который направляет содержание файла на
стандартное устройство вывода.
Например, у вас есть файл file1 версии 1.1 и вы его удалили из
хранилища.
Теперь вы хотите добавить файл к хранилищу снова с тем же содержимым,
которое было
ранее. Ниже привед©н способ как это сделать
$ cvs update -p -r 1.1 file1 >file1 =================================================================== Checking out file1 RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v VERS: 1.1 *************** $ cvs add file1 cvs add: re-adding file file1 (in place of dead revision 1.2) cvs add: use 'cvs commit' to add this file permanently $ cvs commit -m test Checking in file1; /tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1 new revision: 1.3; previous revision: 1.2 done $