CVS.Система управления параллельными версиями
         

Многократное слияние из ветки


Мы продолжаем обсуждение примера. Теперь дерево ревизий выглядит так: +-----+ +-----+ +-----+ +-----+ +-----+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! +---! 1.2.2.1 !----! 1.2.2.2 ! +---------+ +---------+

Здесь линия из звездочек представляет собой слияние ветки `R1fix' с основным стволом, обсуждавшееся только что.

Предположим теперь, что разработка ветки `R1fix' продолжается: +-----+ +-----+ +-----+ +-----+ +-----+ ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 ! +---------+ +---------+ +---------+

и теперь вы опять хотите слить свежайшие изменения с основным стволом. Если бы вы просто использовали команду cvs update -j R1fix m.c, то CVS попыталась бы опять слить уже слитые изменения, что привело бы к нежелательным результатам.

Вместо этого вам нужно указать, что вы хотите слить только те изменения ветки, что еще не были объединены со стволом. Для этого вы указываете два ключа командной строки `-j', и CVS сливает изменения между первой и второй ревизиями. Например, в этом случае самым простым способом будет cvs update -j 1.2.2.2 -j R1fix m.c # Слить изменения между 1.2.2.2 и # головой ветки R1fix

Проблемой здесь является то, что вы должны вручную указать ревизию 1.2.2.2. Чуть лучшим подходом будет использование даты совершения последнего слияния. cvs update -j R1fix:yesterday -j R1fix m.c

Еще лучше было бы помечать ветку `R1fix' после каждого слияния со стволом, и использовать эту метку для дальнейших слияний: cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c

Модули-синонимы


Модули синонимы -- это самый простой вид модулей: mname -a aliases... Это -- простейший путь описания модуля mname. Флаг `-a' означает, что новый модуль будет лишь синонимом для указанного списка модулей: CVS будет обращаться с mname, указанным в командной строке, точно так же, как если бы вместо него был указан список aliases. aliases может содержать имена других модулей или имена каталогов. При использовании имен каталогов CVS создает промежуточные каталоги в рабочем каталоге, как если бы путь был задан явно в командной строке.

Например, если файл `modules' содержит строку amodule -a first-dir

то следующие две команды эквивалентны: $ cvs co amodule $ cvs co first-dir

и обе выдадут одинаковые сообщения: cvs checkout: Updating first-dir U first-dir/file1 U first-dir/file2 cvs checkout: Updating first-dir/sdir U first-dir/sdir/sfile

Начальный импорт


Используйте команду import для начального помещения исходных текстов в репозиторий. Для отслеживания чужих исходников полезно использовать метки поставщика и метки релизов. Метка поставщика -- это символическое имя ветки (всегда имеющей номер 1.1.1, если вы не использовали флаг `-b ветка' (See section Несколько веток поставщика). Метки релизов -- это символические имена конкретной версии продукта, например, `FSF_0_04'.

Заметьте, что import не изменяет каталог, в котором вызвана эта команда. В частности, этот каталог не становится рабочим каталогом для CVS; если вы хотите работать с исходными текстами, сначала импортируйте их, затем извлеките их в другом каталоге (see section Получение исходного кода).

Предположим, что у вас имеются исходные тексты программы, которая называется wdiff, находящиеся в каталоге `wdiff-0.04', и вы хотите сделать изменения для себя, и сохранить их, когда появится новая версия. Начните с импорта исходных текстов в репозиторий: $ cd wdiff-0.04 $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04

В вышеприведенном примере метка поставщика называется `FSF_DIST', а единственная присвоенная метка релиза --- `WDIFF_0_04'.

Начинаем проект под CVS


Так как переименование файлов и перемещение их между каталогами слегка неудобно, первое, что вам следует сделать, когда вы начинаете новый проект -- продумать организацию файлов. Собственно, перемещать и переименовывать файлы можно, но это, во-первых, увеличивает возможность недопонимания, а во-вторых, у CVS есть некоторые неполадки, например, при переименовании каталогов. See section Перемещение и переименование файлов

Дальнейшие действия зависят от конкретной ситуации.

Настройка сервера для парольной аутентификации


Во-первых, вы, вероятно, хотите усилить права доступа к каталогам `$CVSROOT' и `$CVSROOT/CVSROOT'. См. section Прямое соединение с парольной аутентификацией за дополнительными деталями.

На стороне сервера следует редактировать файл `/etc/inetd.conf', чтобы inetd знал, что следует выполнять команду cvs pserver, когда кто-либо пытается соединиться с соответствующим портом. По умолчанию номер порта --- 2401; это значение можно изменить, если перед компиляцией установить параметр CVS_AUTH_PORT в другое значение.

Если ваш inetd позволяет использование номеров портов в `/etc/inetd.conf', то можно использовать такую строку: 2401 stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/usr/cvsroot pserver

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

Ключ командной строки `--allow-root' задает разрешенный каталог CVSROOT. Клиенты, пытающиеся использовать другой каталог, не смогут соединиться. Если вы хотите разрешить доступ к нескольким каталогам CVSROOT, повторите эту опцию.

Если ваш inetd требует текстовых имен сервисов вместо номеров портов, поместите эту строчку в `/etc/services': cvspserver 2401/tcp

и напишите cvspserver вместо 2401 в файле `/etc/inetd.conf'.

После всего этого перезапустите inetd или заставьте его перечитать файлы конфигурации. В случае проблем с настройкой смотрите section Ошибки при установке соединения с CVS-сервером.

Так как клиент хранит и пересылает пароли практически открытым тестом (см. section Прямое соединение с парольной аутентификацией), то может использоваться отдельный файл паролей для CVS, чтобы пользователи не раскрывали своих обычных паролей при доступе к репозиторию. Этот файл -- `$CVSROOT/CVSROOT/passwd' (see section Административные файлы). Его формат похож на `/etc/passwd', но он имеет только два или три поля: имя пользователя, пароль и необязательное имя пользователя для использования сервером. Например: bach:ULtgRLXo7NRxs cwang:1sOp854gDF3DY

Пароль шифруется стандартной функцией UNIX crypt(), поэтому можно просто перенести пароль из обычного файла `passwd'.

При парольной аутентификации сервер сначала проверяет, находится ли пользователь в файле `CVSROOT/passwd'.
Если нет, или файл `CVSROOT/passwd' не существует, то сервер пытается проверить пароль, используя системную процедуру проверки пользователя (это может быть запрещено, установив SystemAuth=no в файле конфигурации, see section Файл конфигурации CVSROOT/config). При использовании файла `CVSROOT/passwd' сервер выполняется с правами пользователя, указанного в третьем поле соответствующей строки, или, если третьего поля нет, то в первом (таким образом CVS позволяет использовать ненастоящие имена пользователей, если в `CVSROOT/passwd' заданы соответствующие им настоящие системные имена. В любом случае, CVS не получит дополнительных прав, кроме тех, что уже имеет пользователь. С помощью файла `CVSROOT/passwd' можно также отобразить пользователей CVS в имена пользователей машины, добавив двоеточие и системное имя пользователя после пароля. Например: cvs:ULtgRLXo7NRxs:kfogel generic:1sOp854gDF3DY:spwang anyone:1sOp854gDF3DY:spwang Таким образом, пользователи, обращающиеся по сети к репозиторию на faun.example.org, используя команду cvs -d :pserver:cvs@faun.example.org:/usr/local/cvsroot checkout foo будут работать с сервером, который имеет права пользователя kfogel, если, конечно, они успешно аутентифицировались. При этом сетевые пользователи не знают системный пароль пользователя kfogel, потому что файл `CVSROOT/passwd' может содержать другой пароль, используемый только CVS-сервером. Как показано в вышеприведенном примере, можно отображать разные имена пользователей CVS в единственного системного пользователя. Эта возможность создана, чтобы позволить доступ к репозиторию без полного доступа к системе (в частности, см. section Доступ к репозиторию только для чтения); однако, смотри также section Прямое соединение с парольной аутентификацией. Любой доступ к репозиторию, скорее всего, подразумевает также некоторый доступ к системе вообще. В настоящее время единственный способ поместить пароль в `CVSROOT/passwd' -- это вырезать его откуда-нибудь еще. Когда-нибудь появится команда cvs passwd.В отличие от других файлов в `$CVSROOT/CVSROOT', вы редактируете файл `CVSROOT/passwd' напрямую, а не с помощью CVS.

Настройка журналирования


Вы можете настроить CVS для журналирования различных действий тем способом, который вам требуется. Это достигается выполнением определенного скрипта в определенные моменты времени. Скрипт может, например, добавить сообщение об изменении в конец какого-либо файла, послать почтовое сообщение группе разработчиков или, например, поместить сообщение в ньюсгруппу. Для того, чтобы журналировать факты фиксирования, используйте файл `loginfo' (see section Файл loginfo).

Для журналирования фиксирований, извлечений, экспортов и меток можно использовать флаги `-i', `-o', `-e' и `-t' соответственно. Эти флаги находятся в файле модулей. Более гибким способом уведомления пользователей, требующим меньше усилий по поддержке централизованных скриптов, является команда cvs watch add (see section CVS может посылать вам уведомления); эта команда полезна, даже если вы не используете cvs watch on.

В файле `taginfo' перечисляются программы, которые нужно выполнить, когда кто-либо выполняет команды CVS tag или rtag. Файл `taginfo' имеет стандартный формат административных файлов (see section Справочник по административным файлам), а каждая строка в нем содержит регулярное выражение, за которым следует команда, которую надо выполнить. Аргументы, которые передаются команде, это имя-метки, операция (add для tag, mov для tag -F, del для tag -d), репозиторий, а затем следует серия пар имя-файла ревизия. Ненулевой код завершения программы приведет к отмене операции с метками.

Вот пример использования `taginfo' для журналирования команд tag и rtag. В файле `taginfo' написано: ALL /usr/local/cvsroot/CVSROOT/loggit

Здесь `/usr/local/cvsroot/CVSROOT/loggit' является таким скриптом: #!/bin/sh echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog

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


По умолчанию, 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 Создание ветвей и слияние).

Несколько разработчиков


Когда над программным проектом работает более одного человека, все усложняется. Зачастую два разработчика одновременно пытаются редактировать один и тот же файл. Одно из решений, известное как блокировка файлов или блокированное извлечение, -- в каждый момент времени позволять редактировать файл только одному человеку. Это -- единственное решение при использовании некоторых систем контроля версий, включая RCS и SCCS. В настоящее время единственным способом совершить блокированное извлечение рабочей копии с помощью CVS -- использовать команду cvs admin -l (see section Ключи команды admin). Это не столь красиво интегрировано в CVS, как функции слежения, описанные ниже, но кажется, что всех, кому требуются блокированное извлечение, эта команда устраивает.

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

Модель, используемая в CVS по умолчанию, называется неблокированные извлечения. В этой модели разработчики редактируют свои собственные рабочие копии файла. Первый, зафиксировавший свои изменения, не может автоматически узнать, что второй также начал редактировать файл. Второй получит сообщения об ошибке, когда попытается зафиксировать файл. Он должен использовать соответствующие команды CVS, чтобы его рабочая копия соответствовала свежайшей ревизии, находящейся в репозитории. Весь этот процесс проходит почти автоматически.

CVS также поддерживает механизмы различных способов коммуникации, никак не настаивая на выполнении каких-либо правил, в отличие от блокированных извлечений.

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

Несколько репозиториев


Иногда необходимо иметь много репозиториев, например, если у вас есть две группы разработчиков, работающих над разными проектами, у которых нет общего кода. Все, что вам требуется, чтобы работать с несколькими репозиториями -- указать необходимый, используя переменную среды CVSROOT, опцию CVS `-d' или (если у вас уже есть рабочий каталог) просто работая по умолчанию с тем репозиторием, из которого был извлечен рабочий каталог (see section Как сообщить CVS, где находится репозиторий.

Серьезным преимуществом нескольких репозиториев является то, что они могут находиться на различных серверах. При использовании CVS 1.10 единственная команда может работать с каталогами из разных репозиториев. С помощью разрабатываемых версий CVS можно извлекать исходные тексты с нескольких серверов. CVS сам разберется с обходом дерева каталогов и соединениями с разными серверами при необходимости. Вот пример создания рабочего каталога: cvs -d server1:/cvs co dir1 cd dir1 cvs -d server2:/root co sdir cvs update

Команды cvs co создают рабочий каталог, а команда cvs update соединится с server2, чтобы обновить каталог `dir1/sdir', и с server1, чтобы обновить все остальное.

Несколько веток поставщика


Все примеры до этого момента подразумевали, что есть только один поставщик, от которого вы получаете исходные тексты. В некоторых ситуациях вы можете получать эти тексты из разных мест. Например, предположим, что вы работаете в проекте, в котором много различных людей и команд изменяют исходный код продукта. Существуют различные способы работы в такой ситуации, но иногда у вас есть несколько деревьев исходников, лежащих рядом, и всё, что вы хотите сделать -- это положить их под CVS, чтобы они по крайней мере находились в одном месте.

Для обработки ситуаций, в которых поставщиков больше одного, вы можете задать команде cvs import ключ `-b'. Этот ключ принимает в качестве параметра номер ветки поставщика. По умолчанию это `-b 1.1.1'.

Например, предположим, что есть две команды: красная и синяя, и обе посылают вам исходные тексты. Вы хотите импортировать результаты работы красной команды в ветку 1.1.1 и использовать метку поставщика `RED'. Вы также хотите импортировать работу синей команды на ветку 1.1.3 и использовать метку поставщика `BLUE'. Вы можете использовать такие команды: $ cvs import dir RED RED_1-0 $ cvs import -b 1.1.3 dir BLUE BLUE_1-5

Заметьте, что если метка поставщика не соответствует ключу `-b', то CVS не обнаружит этот случай! Например, $ cvs import -b 1.1.3 dir RED RED_1-0

Будьте осторожны; такие ошибки совершенно точно приведут, в лучшем случае, к недоразумениям. Не могу придумать полезной цели для возможности намеренного несовпадения в этом месте, а если вы придумаете такой способ, то не используйте его. Скорее всего, в следующих версиях CVS это станет ошибкой.

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

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


Каждая ревизия файла имеет уникальный номер ревизии. Номера ревизий выглядят как `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 Ветки и ревизии.

Обновление извлеченной копии


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

Можно настроить такое поведение с помощью `loginfo', который будет вызывать cvs update. Если сделать это напрямую, то возникнет проблема с блокировками, поэтому cvs update должен выполняться на фоне. Вот пример для операционной системы UNIX (всё это должно помещаться на одной строке): ^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

При такой конфигурации фиксироване изменений в каталогах репозитория, которые начинаются с `cyclic-pages' приведет к обновлению извлеченного дерева, находящегося в `/u/www/local-docs'.

Обновление с помощью импорта


Когда появляется новая версия исходных текстов, вы импортируете их в репозиторий с помощью такой же команды import, которую вы использовали для начального импорта в репозиторий. Единственное различие -- теперь вы используете другую метку релиза. $ tar xfz wdiff-0.05.tar.gz $ cd wdiff-0.05 $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05

Для файлов, которые не были локально изменены, новые созданные ревизии становятся головными ревизиями. Если же локальные изменения были сделаны, import предупредит вас, что вы должны слить изменения в основной ствол и посоветует использовать для этого `checkout -j'. $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff

Вышеуказанная команда извлечет последнюю версию `wdiff', объединяя в рабочую копию изменения, сделанные на ветке поставщика `FSF_DIST' со вчерашнего дня. Если в процессе слияния появляются конфликты, то их нужно разрешить обычным способом (see section Пример конфликта), затем измененные файлы можно зафиксировать.

Использование даты, как предлагается выше, предполагает, что вы импортируете не более одной версии продукта в день. Если же это не так, вы всегда можете использовать что-нибудь типа такого: $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff

В этом случае вышеприведенные команды эквивалентны.

Обработка двоичных файлов


Основное применение для CVS -- хранить текстовые файлы. При работе с текстовыми файлами CVS может объединять ревизии, показывать различия между ревизиями в доступном для человека формате, и совершать прочие подобные операции. Однако, если вы согласитесь отказаться от некоторых возможностей, то CVS может хранить двоичные файлы. Например, можно хранить в CVS целый web-сайт, причем как страницы, так и двоичные картинки.

Общая структура команд CVS


Общий формат всех команд CVS таков: cvs [ опции_cvs ] команда_cvs [ опции_команды ] [ аргументы_команды ] cvs Имя исполняемого файла CVS. cvs_options Некоторые ключи командной строки влияют на все подкоманды CVS. Такие ключи описаны ниже. cvs_command Одна из нескольких подкоманд. Некоторые команды имеют синонимы, которые указываются в справочнике по этой команде. Есть только две ситуации, в которых вы можете пропустить `команду_cvs': `cvs -H' выдает список доступных команд, а `cvs -v' отображает версию CVS. command_options Ключи командной строки, специфичные для каждой команды. command_args Аргументы команд.

К сожалению, есть небольшая путаница между опциями_cvs и опциями_команды. Ключ `-l', когда он используется в качестве опции CVS, воздействует только на некоторые команды. Когда этот ключ используется как опция команды, у него появляется другое значение, и он используется с б'ольшим количеством команд. Другими словами, не придавайте вышеописанной категоризации слишком большого значения, а обращайтесь вместо этого к документации.

Обычные модули


mname [ options ] dir [ files... ] В простейшем случае эта форма описания модуля сокращается до `mname dir'. В этом случае файлы в каталоге dir становятся модулем mname. dir -- путь к каталогу с исходными текстами, относительно $CVSROOT. При извлечении исходных текстов в рабочем каталоге создается каталог mname; по умолчанию не используются промежуточные каталоги, даже если dir состоит из нескольких уровней каталогов.

Например, если модуль описан как regmodule first-dir

то regmodule будет содержать файлы из `first-dir/': $ cvs co regmodule cvs checkout: Updating regmodule U regmodule/file1 U regmodule/file2 cvs checkout: Updating regmodule/sdir U regmodule/sdir/sfile $

Явно указывая в описании модуля после имени каталога имена файлов, можно извлекать их из каталога по отдельности. Вот пример: regfiles first-dir/sdir sfile

При таком описании извлечение модуля regfiles создает единственный рабочий каталог `regfiles', содержащий указанный файл, который берется из каталога `first-dir/sdir/', находящегося в репозитории: $ cvs co regfiles U regfiles/sfile $

Обычный синтаксис


Административные файлы, такие как `commitinfo', `loginfo', `rcsinfo', `verifymsg', и т. д., все имеют общий формат. Назначение этих файлов описано позднее, а здесь описан их общий синтаксис.

Каждая строка содержит следующее: Регулярное выражение: простое регулярное выражение, использующее синтаксис GNU emacs. Разделитель -- один или больше пробелов или символов табуляции. Имя файла или шаблон командной строки.

Пустые строки игнориуются. Строки, которые начинаются с символа `#', считаются комментариями. Длинные строки, к сожалению, не могут быть разбиты на части.

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

Обычный способ переименования


Обычным способом перемещения файла является копирование old в new, а затем выполнение команд CVS для удаления файла old из репозитория и добавления туда файла new. $ mv old new $ cvs remove old $ cvs add new $ cvs commit -m "old переименован в new" old new

Это самый простой способ переместить файл, он не подвержен ошибкам, и сохраняет историю совершенных действий. Заметьте, что для доступа к истории файла нужно указать старое или новое имя, в зависимости от периода истории, к которому вы обращаетесь. Например, cvs log old выдаст журнал вплоть до момента переименования.

Когда new фиксируется, нумерация его ревизий начнется с нуля, обычно с 1.1, поэтому если это вам не нравится, используйте ключ командной строки `-r номер' команды commit. Дальнейшую информацию смотри в section Назначение номеров ревизий.

Обзор


Эта глава предназначена для людей, никогда ранее не использовавших CVS и, возможно, никогда не использовавших управление версиями.

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

Определение модуля


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

В простых случаях нижеследующих шагов достаточно для определения модуля. извлеките рабочую копию файла `modules': $ cvs checkout CVSROOT/modules $ cd CVSROOT отредактируйте этот файл, вставив в него строку, определяющую модуль. См. See section Административные файлы. See section Файл `modules' за полным описанием файла `modules'. Например, для описания модуля `tc' можно использовать такую строку: tc yoyodyne/tc зафиксируйте ваши изменения в файле `modules' $ cvs commit -m "Added the tc module." modules Освободите модуль CVSROOT. $ cd .. $ cvs release -d CVSROOT

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

Ошибки при установке соединения с CVS-сервером


В этой главе обсуждается, что делать, если у вас проблемы с установкой соединения с CVS-сервером. Если вы использует клиент командной строки CVS под Windows, сначала обновите его до версии 1.9.12 или более поздней. Сообщения об ошибках в старой версии предоставляли значительно меньше информации о местонахождении проблемы. Если клиент работает под другой операционной системой, то CVS 1.9 вполне достаточно.

Если сообщений об ошибках недостаточно, чтобы отследить проблему, то следующие шаги сильно зависят от используемого метода доступа. :ext: Попробуйте запустить программу rsh из командной строки. Например, $ rsh servername cvs -v должно выдать информацию о версии CVS. Если это не срабатывает, то ваш сервер нужно исправить, прежде чем беспокоиться о проблемах с CVS. :server: Для того, чтобы использовать этот метод доступа, программа rsh не требуется, но она может быть полезна в качестве средства отладки. Следуйте инструкциям, приведенным для метода `:ext:'. :pserver: Хорошим средством отладки является $ telnet servername 2401 После соединения напечатайте любой текст, например, `foo', нажмите RET. Если CVS работает, то ответом будет cvs [pserver aborted]: bad auth protocol start: foo В противном случае убедитесь, что inetd работает правильно. Замените вызов CVS в файле `/etc/inetd.conf' на программу `echo'. Например: 2401 stream tcp nowait root /bin/echo echo hello Теперь сделайте так, чтобы `inetd' перечитал свой файл конфигурации, попробуйте `telnet' ещё раз, и вы должны увидеть слово `hello', а затем сервер должен закрыть соединение. Если это не так, то нужно исправить ваш `inetd', перед тем, как беспокоиться о CVS. На системах под AIX зачастую порт 2401 уже используется системой. Это проблема AIX в том смысле, что порт 2401 зарегистрирован для CVS. Я слышал, что есть исправление этой проблемы под AIX.

Перемещение файла с ревизиями


Этот метод более опасен, потому что требует перемещения файлов в репозитории. Прочтите всю главу перед попытками применить этот метод! $ cd $CVSROOT/dir $ mv old,v new,v

Преимущества: Журнал изменений сохраняется. Номера ревизий не изменяются.

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

Перемещение и переименование файлов


Перемещение файлов в другой каталог или переименование их несложно, но некоторые аспекты могут быть неочевидными. Перемещение и переименование каталогов еще сложнее. See section Перемещение и переименование каталогов.)

В нижеприведенных примерах предполагается, что файл `old' переименовывается в `new'.

Перемещение и переименование каталогов


Обычный способ переименовать или переместить каталог --- переименовать или переместить каждый файл в нем, как описано в section Обычный способ переименования. Затем следует извлечь их заново, используя ключ командной строки `-P', как описано в section Удаление каталогов.

Если вам действительно нужно возиться с репозиторием, чтобы переименовать или удалить каталог в репозитории, вы можете сделать это так: Уведомить всех, у кого есть извлеченная копия каталога, что каталог будет переименован. Они должны зафиксировать свои изменения и удалить рабочие копии, перед тем, как вы предпримете дальнейшие шаги. Переименуйте каталог внутри репозитория. $ cd $CVSROOT/родительский-каталог $ mv старый-каталог новый-каталог Исправьте административные файлы CVS, если это требуется (например, если вы переименовали целый модуль). Сообщите всем, что они могут извлечь свои рабочии копии опять и продолжить работу.

Если кто-то не удалил свою рабочую копию, команды CVS будут отказываться работать, пока он не удалит каталог, которого больше не существует в репозитории.

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

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

Перемещение репозитория


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

Основная вещь, которую нужно учитывать -- это то, что рабочие каталоги ссылаются на репозиторий. Самый простой способ справиться с этим -- получить свежий рабочий каталог после перемещения. Конечно, вам следует сначала убедиться, что старый рабочий каталог был зафиксирован перед перемещением, или вы уверены, что не потеряете своих изменений. Если вы действительно хотите использовать уже существующий рабочий каталог, то это возможно с помощью хирургического вмешательства в файлы `CVS/Repository'. Смотрите section Как данные хранятся в рабочем каталоге за дополнительной информацией о файлах `CVS/Repository' и `CVS/Root', но если вы не уверены, то, наверное, лучше не пытаться.

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


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

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

Подстановки в административных файлах


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

Для того, чтобы узнать домашний каталог пользователя, который запустил CVS (эта информация хранится в переменной окружения HOME), используйте `~', за которым следует `/' или конец строки. Точно так же, для получения домашнего каталога пользователя используйте `~user'. Подстановка этих переменных происходит на серверной машине, и поэтому такая подстановка не работает, если используется pserver (see section Прямое соединение с парольной аутентификацией). Для того, чтобы изменить поведение для каждого пользователя, лучше использовать пользовательские переменные (см. ниже).

Иногда требуется узнать различную информацию, используемую CVS. Внутренняя переменная CVS имеет такой синтаксис: ${переменная}, где переменная начинается с буквы и состоит из алфавитно-цифровых символов и символа подчерка (`_'). Если символ, который следует за variable, не является буквой, цифрой или знаком подчерка, то фигурные скобки можно опустить. Внутренние переменные CVS таковы: CVSROOT Здесь хранится корневой каталог используемого репозитория. See section Репозиторий, где описаны различные способы задания корневого каталога. RCSBIN В CVS 1.9.18 и раньше в этой переменной находился каталог, в котором находились программы RCS. Так как теперь CVS более не запускает RCS, использование этой внутренней переменной запрещено. CVSEDITOR VISUAL EDITOR Эти три переменных содержат одно и то же значение -- используемый текстовый редактор. See section Глобальные ключи командной строки, где описано, как задать этот редактор. USER Имя пользователя, запустившего CVS (на серверной машине).

Если вы хотите, чтобы пользователь мог задать какое-то значение, передающееся в административный файл, используйте пользовательскую переменную. Для подстановки такой переменной в административном файле написано ${=variable}. Для того, чтобы установить пользовательскую переменную, задайте CVS глобальный флаг `-s' с аргументом переменная=значение. Особенно полезно будет задать такой флаг в файле `~/.cvsrc' (see section Ключи по умолчанию и файл ~/.cvsrc).

Например, если вы хотите, чтобы административный файл ссылался на тестовый каталог, вы можете создать пользовательскую переменную TESTDIR. Затем, если запустить CVS как cvs -s TESTDIR=/work/local/tests

и при административном файле, содержащем sh ${=TESTDIR}/runtests, то эта строка преобразуется в sh /work/local/tests/runtests.

Все другие строки, содержащие `$', зарезервированы; нет способа экранировать символ `$', чтобы он обозначал сам себя.

Получение исходного кода


Сначала вам надо получить рабочую копию исходного кода для `tc'. Используйте команду $ cvs checkout tc

при этом будет создан каталог `tc', в который будут помещены все файлы с исходными текстами. $ cd tc $ ls CVS Makefile backend.c driver.c frontend.c parser.c

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

Вы запускаете свой любимый редактор, работаете над `backend.c' и через пару часов вы добавили фазу оптимизации в компилятор. Замечание для пользователей RCS и RCCS: не требуется блокировать файлы, которые вы желаете отредактировать. See section Несколько разработчиков за объяснением.

Помещение файлов в репозиторий


Первым шагом будет создание файлов в репозитории. Это может быть сделано несколькими различными способами.

Помещение изменений на ветку


Вы можете зафиксировать изменения в ревизию, находящуюся на ветке (в её номере четное количество точек) с помощью ключа `-r'. Для того, чтобы создать ревизию на ветке, используйте ключ `-b' команд rtag и tag (see section Создание ветвей и слияние). Затем используйте checkout или update, чтобы ваши исходные тексты стали основаны на этой свежесозданной ветке. Начиная с этого момента все изменения в этом рабочем каталоге автоматически добавляются в ревизию на ветке, никак не мешая разработке в основном стволе. Например, если вам потребовалось создать исправление к версии 1.2 вашего продукта, несмотря на то, что уже разрабатывается версия 2.0, вы можете: $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module $ cvs checkout -r FCS1_2_Patch product_module $ cd product_module [[ hack away ]] $ cvs commit

Все это будет работать автоматически, потому что ключ `-r' является липким.

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


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

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

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

Права доступа к файлам


Все файлы `,v' создаются с правами только для чтения, и вам не следует изменять права доступа к этим файлам. Каталоги в репозитории должны быть доступны для записи тем, кому разрешено изменять файлы в каждом каталоге. Это обычно означает, что вам нужно создать группу UNIX (см. group(5)), состоящую из лиц, участвующих в создании проекта, и настроить репозиторий так, чтобы эта группа владела каталогом с проектом.

Это означает, что ограничивать доступ к файлам можно только на уровне каталога.

Заметьте, что пользователи также должны иметь права на запись для извлечения файлов, потому что CVS должна создавать файлы блокировки (see section Совместный доступ нескольких разработчиков к CVS).

Заметьте также, что пользователи должны иметь права на запись в файл `CVSROOT/val-tags'. CVS использует этот файл, чтобы отслеживать, какие метки разрешены (этот файл иногда обновляется, когда используются и когда создаются метки).

Каждый RCS-файл принадлежит пользователю, который последним зафиксировал изменения в этот файл. Этот факт не столь важен, главное -- кто владеет каталогами.

CVS пытается установить адекватные права доступа к файлам для новых каталогов, которые создаются в дереве, но если вам требуется, чтобы новый каталог имел права доступа, отличающиеся от его родительского каталога, вы должны задать это вручную. Если вы установите переменную окружения CVSUMASK, то она будет задавать, какие права доступа к файлам CVS использует при создании каталогов и/или файлов в репозитории. CVSUMASK не влияет на права доступа к файлам в рабочем каталоге; такие файлы имеют права, обычные для новых файлов, разве что только иногда CVS создает их с правами только для чтения (смотри главу о слежении, section Слежение за чужими исходными текстами; -r, section Глобальные ключи командной строки; или CVSREAD, section Все переменные окружения, используемые в CVS).

Заметьте, что при использовании клиент-серверного CVS (see section Сетевые репозитории) не существует нормального способа установить CVSUMASK; установка его на клиентской машине не играет роли.
Если вы соединяетесь с помощью rsh, вы можете установить CVSUMASK в файле `.bashrc' или `.cshrc', как описано в документации на вашу операционную систему. Это поведение может измениться в будущей версии CVS; не полагайтесь на то, что установка CVSUMASK на клиентской машине не играет роли. При использовании pserver обычно требуются гораздо более жесткие права доступа к каталогу CVSROOT и каталогам, находящимся в CVSROOT; see section Настройка сервера для парольной аутентификации. Некоторые операционные системы позволяют определенным программам выполнять операции, которые не может выполнять тот, кто вызывает эти программы. Например, возможности setuid или setgid в UNIX или установленные образы в VMS. CVS не разрабатывался, чтобы использовать такие возможности, и поэтому попытки установить CVS таким образом обеспечат защиту только лишь от случайных ошибок; те, кто желает обойти защиту, смогут это сделать и, в зависимости от конкретных условий, смогут получить доступ еще куда-либо помимо CVS. Вы можете попробовать использовать pserver. Эта возможность также способна дать ложное чувство безопасности или открыть дыру, больше чем та, которую вы пытаетесь закрыть, поэтому внимательно прочтите документацию на безопасность pserver, если вы собираетесь его использовать (section Настройка сервера для парольной аутентификации).

При слиянии можно добавлять и удалять файлы


Если измененяи, которые вы сливаете, включают в себя удаление или добавление каких-либо файлов, то команда update -j учтет такие добавления и удаления.

For example: cvs update -A touch a b c cvs add a b c ; cvs ci -m "added" a b c cvs tag -b branchtag cvs update -r branchtag touch d ; cvs add d rm a ; cvs rm a cvs ci -m "added d, removed a" cvs update -A cvs update -jbranchtag

После того, как эти команды выполнены, а также выполнена команда `cvs commit', файл `a' будет удален, а файл `d' будет добавлен в основной ствол.

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

использования Editinfo


Ниже следует небольшой глупый пример файла `editinfo', вместе с соответствующим шаблоном журнального сообщения в файле `rcsinfo' и скрипт редактора. Мы начнем с шаблона журнального сообщения. Предположим, мы хотим хранить номер исправленной ошибки в первой строке журнального сообщения. Остаток журнального сообщения содержит любой описательный текст. В файле `/usr/cvssupport/tc.template' находится такой шаблон: BugId:

Скрипт `/usr/cvssupport/bugid.edit' используется для редактирования журнального сообщения. #!/bin/sh # # bugid.edit filename # # Call $EDITOR on FILENAME, and verify that the # resulting file contains a valid bugid on the first # line. if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi $CVSEDITOR $1 until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1 do echo -n "No BugId found. Edit again? ([y]/n)" read ans case ${ans} in n*) exit 1;; esac $CVSEDITOR $1 done

Файл `editinfo' содержит такую строчку: ^tc /usr/cvssupport/bugid.edit

Файл `rcsinfo' содержит такую строчку: ^tc /usr/cvssupport/tc.template

использования команды `checkout'


Получить копию модуля `tc': $ cvs checkout tc

Получить копию модуля `tc' в том виде, в котором он находился вчера: $ cvs checkout -D yesterday tc

использования loginfo


Нижеследующий файл `loginfo' с помощью крохотного скрипта добавляет журнальные сообщения к файлу `$CVSROOT/CVSROOT/commitlog', а также журналирует в `/usr/adm/cvsroot-log' фиксирование изменений в административных файлах. Журнальные записи, соответствующие фиксированию изменений в каталоге `prog1/' отсылаются по почте пользователю `ceder'. ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log ^prog1 Mail -s %s ceder

Скрипт `/usr/local/bin/cvs-log' выглядит так: #!/bin/sh (echo "------------------------------------------------------"; echo -n $2" "; date; echo; cat) >> $1

Пример конфликта


Предположим, что ревизия 1.4 файла `driver.c' содержит такой код: #include void main() { parse(); if (nerr == 0) gencode(); else fprintf(stderr, "No code generated.\n"); exit(nerr == 0 ? 0 : 1); }

Ревизия 1.6 файла `driver.c' содержит такой код: #include int main(int argc, char **argv) { parse(); if (argc != 1) { fprintf(stderr, "tc: No args expected.\n"); exit(1); } if (nerr == 0) gencode(); else fprintf(stderr, "No code generated.\n"); exit(!!nerr); }

Ваша рабочая копия файла `driver.c', основанная на ревизии 1.4, перед выполнением `cvs update' содержит такой код: #include #include void main() { init_scanner(); parse(); if (nerr == 0) gencode(); else fprintf(stderr, "No code generated.\n"); exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); }

Вы выполняете `cvs update': $ cvs update driver.c RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v retrieving revision 1.4 retrieving revision 1.6 Merging differences between 1.4 and 1.6 into driver.c rcsmerge warning: overlaps during merge cvs update: conflicts found in driver.c C driver.c

CVS сообщает, что вы встретились с конфликтами. Ваш исходный рабочий файл сохранен в `.#driver.c.1.4'. Новая версия `driver.c' содержит такой код: #include #include int main(int argc, char **argv) { init_scanner(); parse(); if (argc != 1) { fprintf(stderr, "tc: No args expected.\n"); exit(1); } if (nerr == 0) gencode(); else fprintf(stderr, "No code generated.\n"); >>>>>> 1.6 }

Заметьте, что непересекающиеся модификации включены в вашу рабочую копию, а пересекающаяся секция четко обозначена строками `, `=======' and `>>>>>>>'.

Разрешить конфликт можно, отредактировав файл, удалив маркеры и неверный вариант. Предположим, в результате у вас получился такой файл: #include #include int main(int argc, char **argv) { init_scanner(); parse(); if (argc != 1) { fprintf(stderr, "tc: No args expected.\n"); exit(1); } if (nerr == 0) gencode(); else fprintf(stderr, "No code generated.\n"); exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE); }

Теперь вы можете поместить этот файл в репозиторий в качестве ревизии 1.7. $ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c Checking in driver.c; /usr/local/cvsroot/yoyodyne/tc/driver.c,v

Чтобы защитить вас, CVS откажется фиксировать файл, если в нем произошел конфликт и вы с ним не справились. В настоящий момент для разрешения конфликта нужно изменить дату модификации файла. В предыдущих версиях CVS вам также требовалось убедиться, что файл не содержит маркеров конфликта. Так как ваш файл действительно может содержать маркеры конфликтов (символы `>>>>>>>>' в начале строки, не обозначающие конфликта), то в текущей версии CVS выдает предупреждение и фиксирует файл.

Если вы используете pcl-cvs (оболочка к CVS для Emacs) версии 1.04 или позже, вы можете использовать пакет emerge, помогающий разрешать конфликты. Смотрите документацию по pcl-cvs.

работы с CVS


В качестве введения в CVS мы приведем здесь типичную сессию работы с CVS. Первое, что необходимо понимать, это то, что CVS хранит все файлы в централизованном репозитории (see section Репозиторий); в этой главе предполагается, что репозиторий настроен.

Предположим, что вы работаете над простым компилятором. Исходный текст состоит из нескольких C-файлов и `Makefile''а. Компилятор называется `tc' (Тривиальный Компилятор), а репозиторий настроен так, что имеется модуль `tc'.

ы использования команды diff


Нижеследующая строка выдает унифицированную (с ключом `-u') разницу между ревизиями 1.14 и 1.19 файла `backend.c'. Из-за наличия флага `-kk' ключевые слова не подставляются, поэтому различия внутри ключевых слов игнорируются. $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c

Предположим, что экспериментальная ветка `EXPR1' была основана на наборе файлов, помеченных как `RELEASE_1_0'. Чтобы увидеть, что произошло на этой ветке, используйте команду $ cvs diff -r RELEASE_1_0 -r EXPR1

Такая команда может использоваться, чтобы показать контекстную разницу между двумя версиями программного продукта: $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs

Если вы пользуетесь файлами `ChangeLog', то команда типа нижеуказанной поможет придумать подходящий текст для журнальной записи. Все изменения, которые вы сделали, будут продемонстрированы вам в удобном виде. $ cvs diff -u | less

ы использования команды import


См. section Слежение за чужими исходными текстами и section Создание дерева каталогов из нескольких файлов.

ы использования команды rdiff


Предположим, вы получаете письмо от foo@example.net, который просит вас прислать обновление с версии 1.2 до версии 1.4 компилятора tc. У вас нету под рукой такого обновления, но с помощью CVS вы можете легко сделать так: $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ $$ Mail -s 'Исправления, которые Вы запрашивали' foo@example.net

Предположим, что вы сделали версию 1.3 и ветку `R_1_3fix' для исправлений этой версии. `R_1_3_1' соответствует версии 1.3.1, которая была сделана некоторое время назад. Теперь вы хотите узнать, что именно было сделано на этой ветке. Можно использовать такую команду: $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name cvs rdiff: Diffing module-name File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6 File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4 File bar.h,v changed from revision 1.29.2.1 to 1.2

ы использования команды release


Освободить каталог `tc' и удалить рабочие копии файлов: $ cd .. # Вам нужно находиться в каталоге, содержащем # ваш каталог с исходными текстами, перед тем, # как вы выполните команду `cvs release'. $ cvs release -d tc You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `tc': y $

Прямое соединение с использованием GSSAPI


GSSAPI -- это общий интерфейс к системам сетевой безопасности, таким как Kerberos 5.

Если у вас есть рабочая библиотека GSSAPI, то ваш CVS может совершать TCP-соединения с сервером, аутентифицируясь с помощью GSSAPI. Для этого CVS нужно скомпилировать с поддержкой GSSAPI; при конфигурировании CVS пытается определить, наличествуют ли в системе библиотеки GSSAPI, использующии Kerberos версии 5. Вы также можете дать configure флаг --with-gssapi.

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

Передаваемые данные по умолчанию не шифруются. Как сервер, так и клиент могут быть скомпилированы с поддержкой шифрования; используйте ключ командной строки configure --enable-encrypt. Для включения шифрования используйте ключ командной строки -x.

Соединения GSSAPI обрабатываются на стороне сервера тем же сервером, что производит парольную аутентификацию; смотри section Настройка сервера для парольной аутентификации. Если вы используете, например, Kerberos, обеспечивающий хорошую аутентификацию, вы, вероятно захочете также устранить возможность аутентифицироваться с использованием паролей открытым текстом. Для этого создайте пустой файл `CVSROOT/passwd' и поместите SystemAuth=no в файл конфигурации `config'.

Сервер GSSAPI использует principal name cvs/имя-машины, где имя-машины -- это каноническое имя сервера. Вам потребуется настроить ваш механизм GSSAPI.

Для соединения с использованием GSSAPI, используйте `:gserver:'. Например, cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo

Прямое соединение с парольной аутентификацией


Клиент CVS также может соединяться с сервером, используя протокол с паролем. Это особенно полезно, когда использование rsh неосуществимо, (например, если сервер находится за файерволлом), и Kerberos также недоступен.

Чтобы использовать этот метод, необходима некоторая настройка как сервера, так и клиентов.

Прямое соединение с помощью Kerberos


Самый простой способ использования Kerberos -- это kerberos rsh, что описано в section Соединение с помощью rsh. Основной недостаток использования rsh -- тот, что все данные должны проходить сквозь дополнительные программы, что замедляет работу. Поэтому если у вас установлен Kerberos, вам следует использовать прямые TCP-соединения, аутентифицируясь с помощью Kerberos.

Эта глава относится к системе Kerberos версии 4. Kerberos версии 5 поддерживается посредством общего интерфейса сетевой безопасности GSSAPI, как описано в предыдущей главе.

CVS должен быть скомпилирован с поддержкой kerberos; при конфигурировании CVS пытается определить, какая версия Kerberos присутствует на машине. Вы можете также использовать ключ командной строки configure --with-krb4.

Пересылаемые данные по умолчанию не шифруются. Как клиент, так и сервер должны быть скомпилированы с использованием шифрования; используйте ключ командной строки configure --enable-encryption. Для включения шифрования используйте глобальный ключ командной строки -x.

На сервере требуется отредактировать /etc/inetd.conf, чтобы запустить cvs kserver. Клиент по умолчанию использует порт 1999; если вы хотите использовать другой порт, задайте его на клиентской машине в переменной окружения CVS_CLIENT_PORT.

Когда вы захотите использовать CVS, сначала, как обычно, получите билет (kinit); этот билет должен позволять вам зарегистрироваться на сервере. Затем cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo

Предыдущие версии CVS могли в случае неудачи использовать соединение с помощью rsh; текущие версии так не делают.

Проблемы с ключевым словом $Log$.


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

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

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

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

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

Просмотр истории


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

Просмотр изменений


Вы не помните, что изменяли файл `driver.c', поэтому хотите посмотреть, что именно случилось с ним. $ cd tc $ cvs diff driver.c

Эта команда сравнивает версию файла `driver.c', находящейся в репозитории, с вашей рабочей копией. Когда вы рассматриваете изменения, вы вспоминаете, что добавили аргумент командной строки, разрешающий фазу оптимизации. Вы фиксируете это изменение и высвобождаете модуль. $ cvs commit -m "Добавлена фаза оптимизации" driver.c Checking in driver.c; /usr/local/cvsroot/tc/driver.c,v

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