ревизии

в большинстве случаев использования cvs не требуется сильно беспокоиться о номерах ревизий; cvs присваивает номера типа 1.1, 1.2 и т. д., и этого достаточно. некоторые, однако, хотели бы иметь больше информации и лучше контролировать то, как cvs присваивает номера ревизий.

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

номера ревизий

каждая ревизия файла имеет уникальный номер ревизии. номера ревизий выглядят как `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'. такие номера означают ревизии, находящиеся на ветках (see section создание ветвей и слияние); эти номера подробно описаны в section ветки и ревизии.

версии и ревизии

как описано выше, у файла может быть несколько ревизий. у программного продукта может быть несколько версий. программным продуктам обычно дают номера версий типа `4.1.1'.

назначение номеров ревизий

по умолчанию, cvs назначает номер ревизии, оставляя первую цифру и увеличивая вторую. например, 1.1, 1.2, 1.3.

при добавлении нового файла вторая цифра всегда будет единицей, а первая цифра будет равняться самой большой первой цифре номера ревизии каждого файла в каталоге. например, если в каталоге находятся файлы с ревизиями 1.7, 3.1, 4.12, то добавленный файл получит номер ревизии 4.1.

обычно совершенно не требуется заботиться о номерах ревизий --- проще думать о них, как о служебных номерах, за которыми следит cvs, а также о метках, обеспечивающих хороший способ различать, например, версию 1 вашего продукта от версии 2 (see section метки ревизий). однако, если вы хотите установить номер ревизии, вам поможет ключ командной строки `-r' команды cvs commit. ключ `-r' подразумевает использование ключа `-f', в том смысле, что он приводит к фиксированию файлов, даже если он не были изменены.

например, для того, что задать всем вашим файлам, включая те, что не изменились, номер ревизии 3.0, выполните команду

$ cvs commit -r 3.0

заметьте, что номер, который вы указываете вместе с ключом `-r', должен быть больше любого существующего номера ревизии. скажем, если существует ревизия 3.0, вы не можете сказать `cvs commit -r 1.3'. если вы хотите параллельно отслеживать несколько версий программного продукта, вам нужно создать ветку (see section создание ветвей и слияние).

метки ревизий

номера ревизий живут своей собственной жизнью. они могут совершенно никак не соотноситься с номером версии вашего программного продукта. в зависимости от того, как вы используете 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, чтобы задать буквенное имя определенной ревизии файла. вы можете использовать ключ командной строки `-v' команды status, чтобы увидеть все метки, которые имеет файл, а также какие номера ревизий они представляют. имена меток должны начинаться с буквы и могут содержать буквы, цифры и знаки `-' и `_'. два имени меток base и head зарезервированы для использования в cvs. предполагается, что будущие зарезервированные имена будут иметь специальный вид, например, начинаться с символа `.', чтобы избежать конфликтов с действительными именами меток.

вы захотите выбрать какое-либо соглашение об именах меток, основываясь, например, на имени программы и номере ее версии. например, можно взять имя программы, за которым следует номер версии, в котором символ `.' заменен на `-', так что cvs 1.9 будет помечен как cvs1-9. если вы выберете стабильные правила именования, вам не придется постоянно угадывать, называется ли метка cvs-1-9, cvs1_9 или как-то еще. вы можете даже принудительно задать эти правила именования в файле `taginfo' (see section настройка журналирования).

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

$ 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, включая разнообразные ключи командной строки, описан в section краткий справочник по командам cvs.

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

$ cvs tag rel-1-0 .
cvs tag: tagging .
t makefile
t backend.c
t driver.c
t frontend.c
t parser.c

(если вы дадите cvs каталог в качестве параметра командной строки, она обычно оперирует над всеми файлами в этом каталоге и, рекурсивно, ко всем подкаталогам, которые тот содержит. see section рекурсивное поведение.)

команда checkout имеет ключ командной строки `-r', позволяющий извлечь определенную ревизию модуля. этот флаг упрощает извлечение исходного текста, из которого сделана версия 1.0 модуля `tc' в когда-нибудь в будущем.

$ cvs checkout -r rel-1-0 tc

это полезно, например, если кто-то заявляет, что в той версии была ошибка, но вы не можете найти ее в текущей рабочей копии.

вы можете также извлечь модуль по состоянию на любую дату. see section ключи команды checkout. задав команде checkout ключ командной строки `-r', следует остерегаться липких меток; см. section липкие метки.

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

        file1   file2   file3   file4   file5

        1.1     1.1     1.1     1.1  /--1.1*      <-*-  tag
        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     (--- <--- look here
        1.3             1.6     1.3              \_
        1.4                     1.4
                                1.5

что пометить в рабочем каталоге

пример в предыдущей секции демонстрирует один из самых распространенных способов выбрать, какие ревизии пометить, а именно: выполнение команды cvs tag без параметров заставляет cvs выбрать ревизии, которые извлечены в текущем рабочем каталоге. например, если копия файла `backend.c' в рабочем каталоге была извлечена из ревизии 1.4, то cvs пометит ревизию 1.4. заметьте, что метка прилагается непосредственно к ревизии 1.4 в репозитории. пометка -- это не изменение файла, и не какая-либо операция, при которой сначала модифицируется рабочий каталог, а затем команда cvs commit переносит изменения в репозиторий.

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

$ cvs tag -c rel-0-4
cvs tag: backend.c is locally modified
cvs [tag aborted]: correct the above errors first!

как помечать по дате или ревизии

команда cvs rtag помечает репозиторий по состоянию на определенную дату и время (может использоваться для пометки последней ревизии). rtag работает прямо с содержимым репозитория (не требуется сначала извлекать рабочий каталог).

нижеследующие ключи командной строки указывают, по какой дате или номеру ревизии помечать. see section стандартные ключи командной строки, где приведено полное описание.

-d дата

помечает самую новую ревизию не позднее даты.

-f

полезно только вместе с `-d дата' или `-r метка'. если не обнаружено соответствующей ревизии, вместо игнорирования файла используется самая новая ревизия.

-r метка

помечать только файлы, содержащие существующую метку метка.

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

cvs tag -r 1.4 backend.c

удаление, перемещение и удаление меток

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

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

чтобы удалить метку, задайте ключ командной строки `-d' команде cvs tag или cvs rtag. например:

cvs rtag -d rel-0-4 tc

удаляет метку rel-0-4 из модуля tc.

когда мы говорим перемещение метки, мы хотим, чтобы существующее имя указывало на другие ревизии. например, метка stable может указывать на ревизию 1.4 файла `backend.c', а мы хотим, чтобы она указывала на ревизию 1.6. чтобы переместить метку, задайте ключ командной строки `-f' командам cvs tag или cvs rtag. например, вышеупомянутая задача может быть решена так:

cvs tag -r 1.6 -f stable backend.c

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

cvs rtag -r old-name-0-4 rel-0-4 tc
cvs rtag -d old-name-0-4 tc

пометки при добавлении и удалении файлов

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

однако, при этом можно потерять небольшое количество информации. например, предположим, что файл был добавлен, а затем удален. затем, если для этого файла отсутствует метка, нет способа сказать, потому ли это, что метка соответствует времени перед тем, как файл был добавлен, или после того, как он был удален. если вы выполните cvs rtag с ключом командной строки `-r', то cvs помечает файлы, которые были удалены, избегая таким образом проблемы. например, можно указать `-r head', чтобы пометить головную ревизию.

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

липкие метки

иногда ревизия, находящаяся в рабочем каталоге, содержит также дополнительную информацию о себе: например, она может находиться на ветке (see section создание ветвей и слияние), или же может быть ограничена с помощью `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' извлекает версию файла из головной ревизии ствола и забывает обо всех липких метках, датах и ключах командной строки.

самое распространенное использование липких меток -- указать, над какой ветвью идет работа, что описано в section доступ к веткам. однако, липкие метки также используются и без веток. предположим, например, что вы хотите избежать обновления вашего рабочего каталога, чтобы защититься от изменений, которые делают ваши коллеги. вы, конечно, можете просто не выполнять команду 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; дальнейшее обсуждение находится в section слияние изменений между двумя ревизиями.

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