Административные файлы

Каталог `$CVSROOT/CVSROOT' содержит несколько административных файлов. Полное их описание в See section Справочник по административным файлам. Можно использовать CVS и без этих файлов, но некоторые команды лучше работают, если хотя бы файл `modules' должным образом настроен. В сущности, этот файл является наиболее важным, в нем описываются все модули в репозитории. Вот пример этого файла: CVSROOT CVSROOT modules CVSROOT modules cvs gnu/cvs rcs gnu/rcs diff gnu/diff tc yoyodyne/tc

Файл `modules' представляет собой текстовый файл. В простейшем случае каждая строка содержит имя модуля, пробел и имя каталога, где находится этот модуль, относительно $CVSROOT.

Строка, которая определяет модуль `modules', использует возможности, здесь не описанные. Полное описание всех доступных возможностей находится в See section Файл `modules'.

Амперсенд-модули

Описание модуля может ссылаться на другие модули, используя запись `&module'. mname [ options ] &module...

При извлечении такого модуля для каждого амперсенд-модуля создается соответствующий подкаталог. Например, если файл `modules' содержит строчку ampermod &first-dir

то при извлечении будет создан каталог `ampermod/', содержащий каталог, который называется `first-dir/', который, в свою очередь, содержит все каталоги и файлы, находящиеся в этом каталоге. Например, команда $ cvs co ampermod

создат следующие файлы: ampermod/first-dir/file1 ampermod/first-dir/file2 ampermod/first-dir/sdir/sfile

В реализации CVS есть одна ошибка: сообщения, которые выдает CVS, не содержат упоминания `ampermod/', и поэтому неправильно сообщают о местонахождении извлеченных файлов: $ cvs co ampermod cvs checkout: Updating first-dir U first-dir/file1 U first-dir/file2 cvs checkout: Updating first-dir/sdir U first-dir/sdir/sfile $

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

База истории

Вы можете использовать файл history (see section Файл history), чтобы журналировать разнообразные действия CVS. Чтобы извлечь информацию из файла history, используйте команду cvs history (see section Файл history).

Блокировки в репозитории

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

Файлы в репозитории, чьи имена начинаются с `#cvs.rfl' --- это блокировки чтения. Файл, чьи имена начинаются с `#cvs.wfl' -- это блокировки записи. Старые версии CVS (перед CVS 1.5) создавали также файлы с именами, начинающимися с `#cvs.tfl', но такие файлы здесь не обсуждаются. Каталог `#cvs.lock' служит главной блокировкой, то есть перед тем, как создавать какую-либо еще блокировку, сначала необходимо создать главную блокировку.

Чтобы создать блокировку чтения, сначала создайте каталог `#cvs.lock'. В большинстве операционных систем операция создания каталога атомарна. Если попытка создания провалилась, значит, главная блокировка уже существует, поэтому подождите немного и попробуйте еще. После получения блокировки `#cvs.lock' создайте файл, чье имя состоит из `#cvs.rfl', и информацией по вашему выбору, например, имя машины и номер процесса. Потом удалите каталог `#cvs.lock', чтобы отменить главную блокировку. Теперь вы можете читать репозиторий. Когда чтение окончено, удалите файл `#cvs.rfl', чтобы отменить блокировку чтения.

Чтобы получить блокировку записи, сначала создайте каталог `#cvs.lock', как и в случае с блокировкой чтения. Затем убедитесь, что в репозитории нет файлов, чьи имена начинаются с `#cvs.rfl'. Если они имеются, удалите `#cvs.lock', подождите немного и попробуйте снова. Если блокировок чтения нет, создайте файл с именем, состоящим из `#cvs.wfl' и какой-нибудь информации по вашему выбору, например, имени машины и номера процесса. Не удаляйте блокировку `#cvs.lock'. Теперь вы можете писать в репозиторий.
Когда запись окончена, сначала удалите файл `#cvs.wfl', а затем каталог `#cvs.lock'. Заметьте, что в отличие от файла `#cvs.rfl', файл `#cvs.wfl' имеет чисто информационное значение; он не оказывает блокирующего эффекта, который в данном случае достигается использованием главной блокировки (`#cvs.lock'). Заметьте, что каждая блокировка (чтения или записи) блокирует единственный каталог в репозитории, включая `Attic' и `CVS', но не включая подкаталоги, которые представляют собой другие каталоги, находящиеся под контролем версий. Чтобы заблокировать целое дерево, вам следует заблокировать каждый каталог (заметьте, что если вы не сможете получить хотя бы одну блокировку в этом процессе, то следует отменить все уже полученные блокировки, затем подождать и попробовать снова, во избежание мертвых блокировок.) Заметьте также, что CVS ожидает, что доступ к отдельным файлам `foo,v' контролируется блокировками записи. RCS использует в качестве блокировок файлы `,foo,', но CVS не поддерживает такую схему, поэтому рекомендуется использование блокировки записи. Смотри комментарии к rcs_internal_lockfile в исходном коде CVS, где находится дополнительное обсуждение и мотивация.

Частичный список сообщений CVS

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

Сообщения перечислены в алфавитном порядке, но вводный текст, такой как `cvs update: ' не учитывается.

В некоторых случаях в этом списке находятся сообщения, которые выдаются старыми версиями CVS (частично из-за того, что пользователи могут быть неуверены, какую версию CVS они используют в настоящий момент). cvs command: authorization failed: server host rejected access Это -- неспецифическое сообщение при попытке соединиться с сервером парольной аутентификации, который отказывает в авторизации без указания конкретной причины. Проверьте, что указанные имя пользователя и пароль верны, и что заданный $CVSROOT разрешен с помощью ключа `--allow-root' в `/etc/inetd.conf'. См. section Прямое соединение с парольной аутентификацией. file:line: Assertion 'text' failed Точный формат этого сообщения может варьироваться в зависимости от вашей системы. Это сообщение указывает на ошибку реализации CVS, что делать с которой, написано в section Что делать с ошибками в CVS и этом руководстве?. cvs command: conflict: removed file was modified by second party Это сообщение указывает, что вы удалили файл, а кто-то еще изменил его в то же самое время. Для того, чтобы справиться с этим конфликтом, сначала выполните `cvs add file'. Если требуется, взгляните на внесенные изменения и выясните, хотите ли вы все еще удалять его. Если нет, то больше ничего делать не надо. Если да, то еще раз скажите `cvs remove file' и зафиксируйте изменения. cannot change permissions on temporary directory Operation not permitted Это сообщение иногда появлялось при выполнении набора тестов под RedHat Linux 3.0.3 и 4.1, причем повторить его, а также выяснить его причину, мы не смогли. Неизвестно, проявляется ли эта ошибка только под Linux (или вообще только на этой конкретной машине!).
Если проблема не случается на других UNIXах, то, скорее всего, сообщением об ошибке будет `Not owner' или другое сообщение, возникающее при ошибке EPERM, вместо `Operation not permitted'. Если вы можете что-то добавить, сообщите нам, как описано в section Что делать с ошибками в CVS и этом руководстве?. Если вы сталкиваетесь с этой ошибкой при использовании CVS, следует повторить операцию, и она пройдет успешно. cannot open CVS/Entries for reading: No such file or directory Обычно это означает внутреннюю ошибку CVS, с которой можно справиться так же, как и с другими (see section Что делать с ошибками в CVS и этом руководстве?). Обычно эту ошибку можно обойти. Надеемся, что в конкретной ситуации будет ясно, как это сделать. cvs [init aborted]: cannot open CVS/Root: No such file or directory Это сообщение совершенно безвредно. Если оно не сопровождается другими сообщениями об ошибке, значит, операция завершится успешно. Это сообщение не должно появляться в свежих версиях CVS, но документировано здесь для удобства пользователей версий CVS 1.9 и раньше. cvs [checkout aborted]: cannot rename file file to CVS/,,file: Invalid argument Это сообщение, по отзывам, появляется от случая к случаю при работе с CVS 1.9 под Solaris 2.5. Причина неизвестна; если вы можете что-нибудь сказать по этмоу поводу, сообщите нам, как описано в section Что делать с ошибками в CVS и этом руководстве?. cvs [command aborted]: cannot start server via rcmd Это, к сожалению, довольно неспецифическое сообщение об ошибке, которое CVS версии 1.9 выдает, если вы выполняете клиента CVS и при соединении с сервером появляются проблемы. Текущие версии CVS должны выдавать более конкретное сообщение. Если вы получили это сообщение, совершенно не имея в виду запускать клиента CVS, значит, вероятно, вы забыли указать :local:, как описано в section Репозиторий. ci: file,v: bad diff output line: Binary files - and /tmp/T2a22651 differ CVS 1.9 и старше выдают это сообщение при попытке зафиксировать измененный двоичный файл, если система RCS установлена неправильно.


Перечитайте инструкции из дистрибутива RCS и файл `INSTALL' в дистрибутиве CVS. Еще можно обновить версию CVS, которая сама будет заниматься фиксированием, без необходимости использовать RCS. cvs checkout: could not check out file При работе с CVS 1.9 это сообщение может означать, что программа co (из комплекта RCS) завершилась с ошибкой. Перед этим сообщением должно быть другое, с объяснением причины, однако, наблюдались и ситуации с отсутствием оного, которые так и не объяснены. При работе с текущей версией CVS, которая не использует co, появление этого сообщения без сопровождающего объяснения определенно означает ошибку в CVS (see section Что делать с ошибками в CVS и этом руководстве?). cvs [login aborted]: could not find out home directory Это означает, что вам требуется установить переменные окружения, которые CVS использует, чтобы найти ваш домашний каталог. См. обсуждение `$HOME', `$HOMEDRIVE' и `$HOMEPATH' в section Все переменные окружения, используемые в CVS. cvs update: could not merge revision rev of file: No such file or directory CVS 1.9 и раньше выдают это сообщение, если не смогли найти программу rcsmerge. Убедитесь, что она находится в вашем PATH, или поставьте свежую версию CVS, которая не требует внешней программы rcsmerge. cvs [update aborted]: could not patch file: No such file or directory Это означает, что не обнаружена программа patch. Убедитесь, что она находится в вашем PATH. Заметьте, что, несмотря на формулировку сообщения, оно не относится к файлу `file'. Если клиент и сервер оба используют текущую версию CVS, то внешняя программа patch не требуется и вы не должны получать такое сообщение. Если же клиент либо сервер используют CVS 1.9, то программа patch требуется. cvs update: could not patch file; will refetch Это означает, что по какой-то причине клиент не смог применить файл изменений, посланный ему сервером. Можно не беспокоиться, получив это сообщение -- работа CVS просто несколько замедлится, но никак гне повлияет на конечный результат. dying gasps from server unexpected В сервере версий CVS 1.9.18 и раньше имеется известная ошибка, приводящая к такому сообщению.


У меня лично получалось вызывать её, используя глобальный ключ `-t'. Эта ошибка в файле `src/filesubr.c' была исправлена Энди Пайпером (Andy Piper) 14 ноября 1997 года, если кому-то интересно. Если вы видите это сообщение, просто повторите команду, или, если вы обнаружили её причину, дайте нам знать, как описано в section Что делать с ошибками в CVS и этом руководстве?. end of file from server (consult above messages if any) Самая распространенная причина этого сообщения -- вы используете внешнюю программу rsh и она завершилась с кодом ошибки. В этом случае она должна была напечатать сообщение, которое появится перед обсуждаемым сообщением. Дальнейшая информация о настройке клиента и сервера CVS находится в section Сетевые репозитории. cvs commit: Executing 'mkmodules' Это означает, что ваш репозиторий настроен для версии CVS раньше 1.8. При использовании CVS 1.8 и позже перед обсуждаемым сообщением появится еще одно: cvs commit: Rebuilding administrative file database Если вы видите оба сообщения, то база данных перестраивается дважды, что необязательно, но нестрашно. Если вы хотите избежать ненужной работы, и не используете версию CVS 1.7 или раньше, удалить -i mkmodules везде, где эта строка появляется в файле `modules'. Дальнейшая информация об этом файле находится в section Файл `modules'. missing author Обычно это происходит, если вы создали RCS-файл с пустым именем пользователя. CVS может по ошибке создать такой файл. Решение -- убедиться, что имя пользователя установлено в непустое значение и пересоздать RCS-файл. *PANIC* administration files missing Это обычно означает, что существует каталог `CVS/', но в нем нет административных файлов, которые обычно помещает туда CVS. Если проблема в том, что вы создали каталог `CVS/' как-то по-другому, не с помощью CVS, то ответ прост -- используйте другое имя. В противном случае это сообщение означает ошибку в CVS (see section Что делать с ошибками в CVS и этом руководстве?). rcs error: Unknown option: -x,v/ Вслед за этим сообщением будет информация о правильном использовании RCS.


Это означает, что у вас старая версия RCS (вероятно, входящая в комплект операционной системы). CVS работает только с RCS версии 5 и старше. cvs [server aborted]: received broken pipe signal Это сообщение вызывается какой-то очень сложной ошибкой в CVS или системах, под которыми CVS работает (мы не знаем, какой именно, потому что еще не отследили эту ошибку!). Кажется, она возникает только после завершения команды CVS, и вам, скорее всего, нужно лишь игнорировать это сообщение. Однако, если вы обнаружили причину этого сообщения, дайте нам знать, как описано в section Что делать с ошибками в CVS и этом руководстве?. Too many arguments! Обычно это сообщение выдается скриптом `log.pl', находящимся в каталоге `contrib/' в дистрибутиве CVS. В некоторых версиях CVS этот скрипт устанавливался по умолчанию. Он вызывается из административного файла `loginfo'. Проверьте, что аргументы, которые передаются этому скрипту из файла `loginfo', совпадают с теми, которые ожидаются. В частности, `log.pl' из CVS 1.3 и раньше ожидает имя журнального файла в качестве аргумента, тогда как `log.pl' версии 1.5 и новее получает имя журнального файла с помощью ключа `-f'. Конечно, если вам не нужен `log.pl', то просто закомментируйте его в `loginfo'. cvs [login aborted]: unrecognized auth response from server Это сообщение обычно означает, что сервер не был настроен должным образом. Например, строка в файле `/etc/inetd.conf' задает имя несуществующего исполняемого файла. Для исправления ошибок найдите журнальный файл, используемый `inetd''ом, например, `/var/log/messages'. Детали обсуждаются в section Ошибки при установке соединения с CVS-сервером и section Настройка сервера для парольной аутентификации. cvs commit: Up-to-date check failed for `file' Это означает, что кто-либо еще зафиксировал изменения в файл с тех пор, как вы последний раз делали cvs update. Сделайте cvs update и повторите cvs commit. CVS объединит изменения, которые сделали вы, с изменениями, сделанными остальными. Если не случится конфликтов, то CVS выдаст сообщение `M cacErrCodes.h', и можно сразу выполнять cvs commit.


Если обнаружены конфликты, то CVS сообщит об этом, сказав, что `C cacErrCodes.h', и вам потребуется вручную устранить конфликт. Дальнейшие детали этого процесса обсуждаются в section Пример конфликта. Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3 Only one of [exEX3] allowed Это указывает на проблему с установленными программами diff3 и rcsmerge. Точнее говоря, rcsmerge скомпилирован так, что должен использовать GNU-версию diff3, а вместо этого находит UNIX-версию. Точный текст сообщения разный на разных системах. Самым простым решением будет обновить версию CVS, которая не использует внешних программ rcsmerge и diff3. warning: unrecognized response `text' from cvs server Если text содержит разрешенный текст ответа (например, `ok'), за которым следует дополнительный символ воврата каретки (на многих системах это приведет к тому, что вторая часть сообщения перезапишет первую часть), то это, вероятно, означает, что вы используете метод доступа `:ext:' с такой версией rsh, которая, как большинство не-UNIX версий, не обеспечивает прозрачного потока данных. В этом случае попробуйте `:server:' вместо `:ext:'. Если в text содержится что-то ещё, это может означать проблемы с вашим CVS-сервером. Ещё раз проверьте, как вы установили CVS-сервер. cvs commit: [time] waiting for user's lock in directory Это нормальное сообщение, а не ошибка. Смотри section Совместный доступ нескольких разработчиков к CVS, где описаны детали. cvs commit: warning: editor session failed Это означает, что редактор, используемый CVS, возвращает ненулевой код завершения. Некоторые версии vi делают это даже в том случае, если при редактировании файла не было ни одной ошибки. Если это так, то пусть ваша переменная окружения `CVSEDITOR' указывает на маленький скрипт, например #!/bin/sh vi $* exit 0

Чем не является CVS?

CVS сделает для вас множество вещей, но не пытается быть всем сразу. CVS не является системой управления сборкой. Несмотря на то, что структуры вашего репозитория и файла модулей взаимодействуют с системой управления сборкой (то есть файлами `Makefile'), они принципиально независимы. CVS не указывает, как собирать тот или иной проект. Она просто хранит файлы, предоставляя возможность обращаться к ним, используя задуманную вами структуру дерева. CVS не указывает, как использовать дисковое пространство в извлеченных каталогах. Если вы создадите `Makefile' или скрипты в каждом каталоге так, что они должны знать относительную позицию всего остального, то дело кончится тем, что придется извлекать весь репозиторий. Если вы модуляризуете вашу работу и создадите систему сборки, которая будет совместно использовать файлы, (посредством ссылок, монтирования, VPATH в `Makefile''ах и т. д.), то сможете использовать дисковое пространство любым угодным вам способом. Помните только, что любая подобная система требует серьезной работы по созданию и поддержанию. CVS не пытается справиться с возникающими при этом вопросами. Конечно же, вам следует поместить средства, созданные для поддержки системы сборки (скрипты, `Makefile''ы, и т. д.), под CVS. Выяснение того, какие файлы следует перекомпилировать при каком-либо изменении, опять же, не является задачей CVS. Традиционным подходом является использование make для сборки, и использование специальной утилиты для генерации зависимостей, используемых программой make. Смотри главу section Как ваша система сборки взаимодействует с CVS за дальнейшей информацией о сборках проектов с участием CVS. CVS не является заменой руководителю Предполагается, что вы общаетесь с вашим начальником и лидером проекта достаточно часто, чтобы знать о графике работ, точках слияния, именах веток и датах выпуска. Если это не так, что CVS никак не сможет помочь. CVS -- это инструмент, заставляющий ваш код плясать под вашу дудку. Но вы и композитор, и исполнитель. Ни один инструмент не играет сам и не сочиняет собственной музыки.
CVS не является заменой общения разработчиков. Встретившись с конфликтом, состоящим из единственной строки, большинство разработчиков справляются с ними без особого труда. Однако, более общее определение конфликта включает в себя проблемы, которые слишком трудно решить без взаимодействия разработчиков. CVS не может обнаружить, что синхронные изменения в одном или нескольких файлах привели к логическому конфликту. Понятие конфликт, которое использует CVS, строго текстуально. Такие конфликты появляются, когда изменения в основном файле достаточно близки, чтобы напугать программу слияния (то есть diff3). CVS совершенно неспособна помочь в устранении нетекстуальных или распределенных конфликтов в логике программы. Пример: предположим, вы изменили аргументы функции X, описанной в файле `A'. В то же самое время кто-то еще редактирует файл `B', добавив новый вызов функции X, используя старые аргументы. CVS ничем не сможет помочь. Возьмите привычку читать спецификации и беседовать с коллегами. CVS не ведет контроля изменений Под контролем изменений имеется в виду несколько вещей. Во-первых, это может означать отслеживание ошибок, то есть хранение базы данных обнаруженных ошибок и состояние каждой (исправлена ли она? в какой версии? согласился ли обнаруживший ее, что она исправлена?). О взаимодействии с внешней системой отслеживания ошибок можно прочитать в файлах `rcsinfo' и `verifymsg' (see section Справочник по административным файлам). Другим аспектом контроля изменений является отслеживание того факта, что изменения в нескольких файлах в действительности являются одним и тем же согласованным изменением. Если вы фиксируете несколько файлов одной командой cvs commit, то CVS забывает, что эти файлы были зафиксированы одновременно, и единственная вещь, их объединяющая -- это одинаковые журнальные записи. В данном случае может помочь ведение файла `ChangeLog' в стиле GNU. Еще одним аспектом контроля изменений, в некоторых системах является возможность отслеживать статус каждого изменения.


Некоторые изменения были написаны разработчиком, некоторые были изучены другим разработчиком, и так далее. Обычно при работе с CVS в этом случае создается diff-файл, (используя cvs diff или diff), который посылается по электронной почте кому-нибудь, кто потом применит этот diff-файл, используя программу patch. Это очень гибко, но зависит от внешних по отношению к CVS механизмов, чтобы убедиться, что ничего не упущено. CVS не является системой автоматического тестирования Впрочем, имеется возможность принудительного выполнения серии тестов, используя файл `commitinfo'. Я, однако же, не очень много знаю о проектах, использовавших эту возможность, и есть ли в ней какие-нибудь ловушки и подводные камни. CVS не имеет встроенной модели процесса Некоторые системы обеспечивают способы убедиться, что изменения и релизы проходят через определенные ступени, получая одобрение на каждой. Вообще говоря, этого можно добиться с помощью CVS, но это может потребовать немного больше работы. В некоторых случаях вы будете использовать файлы `commitinfo', `loginfo', `rcsinfo' или `verifymsg', чтобы убедиться, что предприняты определенные шаги, прежде чем CVS позволит зафиксировать изменение. Подумайте также, должны ли использоваться такие возможности, как ветви разработки и метки, чтобы, скажем, поработать над новой веткой разработки, а затем объединять определенные изменения со стабильной веткой, когда эти изменения одобрены.

Чердак

Вы заметите, что иногда CVS помещает RCS-файлы в каталоге Attic ("чердак"). Например, если CVSROOT -- это `/usr/local/cvsroot', и мы говорим о файле `backend.c' в каталоге `yoyodyne/tc', то обычно этот файл находится в /usr/local/cvsroot/yoyodyne/tc/backend.c,v

Если же он попадает на чердак, то он будет находиться в /usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v

С точки зрения пользователя неважно, находится файл на чердаке или нет, так как CVS сам следит за этим и при необходимости заглядывает на чердак в поисках файла. В случае же, если вы хотите знать точно, то RCS-файл хранится на чердаке тогда и только тогда, когда головная ревизия ствола находится в состоянии dead ("мертвое"). "Мертвое" состояние означает, что файл был удален или же никогда не добавлялся в эту ветку. Например, если вы добавите файл в ветку, то его стволовая ревизия будет в "мертвом" состоянии, а ревизия на ветке -- нет.

Что делать с ошибками в CVS и этом руководстве?

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

Если вы хотите, чтобы кто-нибудь помог вам и исправил найденные ошибки, есть компании, которые сделают это за определенную плату. Вот две такие компании: Signum Support AB Box 2044 S-580 02 Linkoping Sweden Email: info@signum.se Phone: +46 (0)13 - 21 46 00 Fax: +46 (0)13 - 21 47 00 http://www.signum.se/ Cyclic Software United States of America http://www.cyclic.com/ info@cyclic.com Если вы получили CVS от распространителя, например, производителя операционной системы или поставщика компакт-дисков со свободным программным обеспечением, вы можете выяснить, предоставляет ли этот распространитель поддержку. Обычно они этого не делают, или же предоставляют предельно минимальную поддержку, но у разных распространителей по разному. Если ваши способности и время позволяют, вы можете сами исправить ошибку. Если вы хотите, чтобы ваше исправление вошло в очередную версию CVS, смотрите файл `HACKING' в дистрибутиве исходных текстов CVS. Там содержится гораздо больше информации о процессе внесения исправлений. В сети могут быть ресурсы, которые могут помочь. Два хороших места для начала таковы: http://www.cyclic.com http://www.loria.fr/~molli/cvs-index.html Если вы вдохновитесь чем-нибудь, то мы будем очень признательны за увеличение количества информации, доступной в сети. Например, до того, как стандартный дистрибутив CVS заработал под Windows 95, была создана web-страница с объяснениями и заплатами, а различные участники списка рассылки помогали, упоминая эту страницу при возникновении вопросов. Можно также сообщить об ошибке в bug-cvs. Заметьте, что необязательно ваше сообщение об ошибке будет учтено.
Что делать, если вам требуется решение -- описано выше. В основном там хотят слышать об особенно опасных или легких ошибках. Вы можете увеличить шансы успешного исхода, максимально четко описав ошибку и добавив всю необходимую дополнительную информацию. Сообщить об ошибке можно, отправив письмо по адресу bug-cvs@gnu.org. Заметьте, что исправления, оказавшиеся в bug-cvs, могут распространяться на условиях Публичной Лицензии GNU. Если вам это не нравится -- не присылайте исправление. you don't like this, don't submit them. There is usually no justification for sending mail directly to one of the CVS maintainers rather than to bug-cvs; those maintainers who want to hear about such bug reports read bug-cvs. Also note that sending a bug report to other mailing lists or newsgroups is not a substitute for sending it to bug-cvs. It is fine to discuss CVS bugs on whatever forum you prefer, but there are not necessarily any maintainers reading bug reports sent anywhere except bug-cvs. Часто задают вопрос, имеется ли список известных ошибок, и известна ли уже конкретная ошибка. Файл `BUGS' в дистрибутиве исходных текстов CVS является одним из таких списков известных ошибок, но он необязательно полон. Возможно, полного списка никогда не будет. Go to the first, previous, next, last section, table of contents.

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

Пример в предыдущей секции демонстирует один из самых распространенных способов выбрать, какие ревизии пометить, а именно: выполнение команды 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?

Не помнящие прошлого обречены повторять его. -- Джордж Сантаяна

CVS -- это система контроля версий. Используя ее, вы можете вести историю ваших файлов с исходными текстами.

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

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

CVS также поможет, если вы являетесь членом группы разработчиков одного проекта. Очень легко попортить чужие изменения, если только вы не крайне аккуратны. Некоторые редакторы, такие как GNU Emacs, стараются проследить, чтобы два человека не изменяли одновременно один и тот же файл. К сожалению, если кто-то использует другой редактор, эта предосторожность не сработает. CVS решает эту проблему, изолируя разработчиков друг от друга. Каждый работает в своем собственном каталоге, а затем CVS объединяет законченные работы.

CVS появился из набора sh-скриптов, автором которых был Dick Grune, опубликованных в ньюсгруппе comp.sources.unix в томе 6 в декабре 1986 года. Несмотря на то, что ни строчки кода из тех скриптов не присутствует в CVS, основы алгоритма устранения конфликтов взяты именно оттуда.

В апреле 1989 года Brian Berliner спроектировал и реализовал CVS. Jeff Polk позднее помог ему с поддержкой модулей и ветвей поставщика.

Получить CVS можно разными способами, включая свободное получение в Интернете. За информацией о получении и по другим вопросам обращайтесь на: http://www.cyclic.com/ http://www.loria.fr/~molli/cvs-index.html

Имеется список рассылки info-cvs, посвященный обсуждению CVS. Чтобы подписаться на него или отписаться, пишите на info-cvs-request@gnu.org.

Если вы предпочитаете группы новостей usenet, найдите comp.software.config-mgmt, посвященную обсуждению разнообразных систем управления конфигурацией, не только CVS. В будущем возможно создание comp.software.config-mgmt.cvs, если в comp.software.config-mgmt будет наличествовать достаточное количество обсуждений CVS.

Можно также подписаться на список рассылки bug-cvs, о котором подробно рассказывается в section Что делать с ошибками в CVS и этом руководстве?. Чтобы подписаться, напишите на bug-cvs-request@gnu.org.

CVS может посылать вам уведомления

Вы можете сказать CVS, что хотели бы получать уведомления о разнообразных действиях, совершенных с файлом. В принципе вы можете сделать это без использования cvs watch on, но обычно все же будете использовать как раз cvs watch on, чтобы другие разработчики использовали команду cvs edit.

Команда: cvs watch add [-a действие] [-lR] файлы ...

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

Ключ командной строки -a задает тип событий, о которых следует посылать уведомления. действие -- это edit Другой пользователь выполнил для файла команду cvs edit (описанную ниже). unedit Другой пользователь выполнил команду cvs unedit (описанную ниже) или команду cvs release, или удалил файл и позволил команде cvs update создать его заново. commit Другой пользователь зафиксировал изменения в файле. all Все эти действия. none Ни одно из этих действий. (Это полезно вместе с cvs edit, описанной ниже.)

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

Файлы и ключи командной строки обрабатываются так же, как и в команде cvs watch.

Команда: cvs watch remove [-a действие] [-lR] файлы ...

Удалить запрос на уведомление, созданный с помощью cvs watch add; аргументы те же самые. Если присутствует ключ командной строки -a, то только удаляются только слежения за указанными действиями.

Когда требуется отправить уведомление, CVS обращается к административному файлу `notify'. Этот файл можно отредактировать точно так же, как и другие административные файл (see section Административные файлы). Синтаксис этого файла подобен другим административным файлам (see section Обычный синтаксис), где каждая строка состоит из регулярного выражения и команды, которую надо выполнить. Команда должна содержать одно единственное упоминание символов `%s', которые будут заменены на имя пользователя, которого нужно уведомить; остальная информация передается этой команде на стандартный вход. Обычно в файл `notify' помещается такая строка: ALL mail %s -s \"CVS notification\"

В результате всего этого пользователи получают уведомления по электронной почте.

Заметьте, что если вы настроите все именно так, как рассказано выше, то пользователи будут получать уведомления на сервере. Конечно же, можно написать скрипт `notify', который перенаправляет уведомления на другой адрес, но, для простоты, CVS позволяет задать адрес, по которому следует отсылать уведомления пользователю. Для этого создайте в `CVSROOT' файл `users', в котором каждая строка имеет вид пользователь:адрес. Тогда вместо того, чтобы использовать имя пользователя, CVS будет использовать адрес.

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

CVS -- Система Управления Параллельными Версиями

Обзор Что такое CVS? Чем не является CVS? Пример работы с CVS Получение исходного кода Фиксирование изменений Уборка за собой Просмотр изменений Репозиторий Как сообщить CVS, где находится репозиторий Как данные хранятся в репозитории Где хранятся файлы в репозитории Права доступа к файлам Специфические для Windows права доступа Чердак Каталог CVS в репозитории Блокировки в репозитории Как в каталоге CVSROOT хранятся файлы Как данные хранятся в рабочем каталоге Административные файлы Редактирование административных файлов Несколько репозиториев Создание репозитория Резервное копирование репозитория Перемещение репозитория Сетевые репозитории Требования к серверу Соединение с помощью rsh Прямое соединение с парольной аутентификацией Настройка сервера для парольной аутентификации Использование клиента с парольной аутентификацией Вопросы безопасности при парольной аутентификации Прямое соединение с использованием GSSAPI Прямое соединение с помощью Kerberos Использование параллельного cvs server для соединения Доступ к репозиторию только для чтения Временные каталоги на сервере Начинаем проект под CVS Помещение файлов в репозиторий Создание дерева каталогов из нескольких файлов Создание файлов из других систем контроля версий Создание дерева каталогов с нуля Определение модуля Ревизии Номера ревизий Версии и ревизии Назначение номеров ревизий Метки ревизий Что пометить в рабочем каталоге Как помечать по дате или ревизии Удаление, перемещение и удаление меток Пометки при добавлении и удалении файлов Липкие метки Создание ветвей и слияние Для чего хороши ветви? Создание ветви Доступ к веткам Ветки и ревизии Волшебные номера веток Слияние веток Многократное слияние из ветки Слияние изменений между двумя ревизиями При слиянии можно добавлять и удалять файлы Рекурсивное поведение Добавление, удаление и переименование файлов и каталогов Добавление файлов в каталог Удаление файлов Удаление каталогов Перемещение и переименование файлов Обычный способ переименования Перемещение файла с ревизиями Копирование файла с ревизиями Перемещение и переименование каталогов Просмотр истории Журнальные записи База истории Настройка журналирования Команда annotate Обработка двоичных файлов Вопросы использования двоичных файлов Как хранить двоичные файлы Несколько разработчиков Статус файла Извлечение свежей ревизии файла Пример конфликта Информирование коллег о фиксировании ревизий Совместный доступ нескольких разработчиков к CVS Как отследить, кто редактирует файлы? Как с помощью CVS следить за определенными файлами? CVS может посылать вам уведомления Как редактировать файлы, за которыми наблюдают? Информация о том, кто следит и кто редактирует Использование слежений со старыми версиями CVS Выбор между блокированными и неблокированными извлечениями Управление ревизиями Когда фиксировать изменения? Подстановка ключевых слов Список ключевых слов Использование ключевых слов Как избежать подстановки Режимы подстановки Проблемы с ключевым словом $@asis{}Log$. Слежение за чужими исходными текстами Начальный импорт Обновление с помощью импорта Возврат к последней версии от поставщика Как обрабатывать двоичные файлы при импорте в CVS Как обрабатывать замену ключевых слов при импорте в CVS Несколько веток поставщика Как ваша система сборки взаимодействует с CVS Специальные файлы Руководство по командам CVS Общая структура команд CVS Код выхода CVS Ключи по умолчанию и файл ~/.cvsrc Глобальные ключи командной строки Стандартные ключи командной строки Команда admin: администрирование Ключи команды admin Команда checkout: извлечение исходных текстов для редактирования Ключи команды checkout Пример использования команды `checkout' Команды commit: поместить файлы в репозиторий Ключи команды commit Пример использования команды commit Помещение изменений на ветку Создание ветки после редактирования Команда diff: показать различия между ревизиями Ключи команды diff Примеры использования команды diff Команда export: экспортировать исходные тексты Ключи команды export Команда history: показать состояние файлов и пользователей Ключи команды history Команда import: импортировать исходные тексты Ключи команды import Сообщения команды output Примеры использования команды import Команда log: напечатать информацию о файлах Ключи команды log Примеры использования команды log Команда rdiff: выдать изменения между версиями в формате patch Ключи команды rdiff Примеры использования команды rdiff Команда release: сообщить, что модуль более не используется Ключи команды release Сообщения команды release Примеры использования команды release Команда update: обновить рабочий каталог из репозитория Ключи команды update Сообщения команды update Краткий справочник по командам CVS Справочник по административным файлам Файл `modules' Модули-синонимы Обычные модули Амперсенд-модули Исключение каталогов из списка Флаги модулей Файл `cvswrappers' Выполнение программ на разных стадиях фиксирования Обычный синтаксис Файл `commitinfo' Проверка журнальных записей Файл `editinfo' Пример использования Editinfo Файл loginfo Пример использования loginfo Обновление извлеченной копии Файл rcsinfo Игнорирование файлов с помощью cvsignore Файл history Подстановки в административных файлах Файл конфигурации CVSROOT/config Все переменные окружения, используемые в CVS Совместимость между версиями CVS Исправление ошибок Частичный список сообщений CVS Ошибки при установке соединения с CVS-сервером Другие распространенные проблемы Титры Что делать с ошибками в CVS и этом руководстве? Индекс

This document was generated on 28 November 1999 using texi2html 1.56k.

Для чего хороши ветви?

Предположим, был выпущен tc версии 1.0. Вы продолжаете его разработку, планируя выпустить версию 1.1 через пару месяцев. Через некоторое время ваши пользователи начинают жаловаться на серьезную ошибку. Вы извлекаете версию 1.0 (see section Метки ревизий) и находите ошибку, для исправления которой требуется всего лишь тривиальное изменение). Однако же, текущая версия исходников находится в крайне нестабильном состоянии и не стабилизируется по крайней мере еще месяц. Вы не можете выпустить исправленную версию, основываясь на свежих исходниках.

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

Добавление файлов в каталог

Для того, чтобы добавить новый файл в каталог, совершите следующие шаги: Сначала у вас должна быть рабочая копия каталога. See section Получение исходного кода. Создайте новый файл в рабочей копии каталога. Используйте `cvs add имя_файла', чтобы сообщить CVS, что вы хотите хранить историю изменений этого файла. Если в файле хранятся двоичные данные, добавьте ключ командной строки `-kb' (see section Обработка двоичных файлов). Используйте команду `cvs commit имя_файла', чтобы поместить файл в репозиторий. Другие разработчики не увидят этот файл, пока вы не выполните эту команду.

Можно также использовать команду add для добавления нового каталога.

В отличие от большинства других команд, команда add не является рекурсивной. Вы даже не можете сказать `cvs add foo/bar'. Вместо этого, вам потребуется выполнить $ cd foo $ cvs add bar

Команда: cvs add [-k kflag] [-m сообщение] файлы ...

Добавить файлы в список на помещение в репозиторий. Файлы или каталоги, указанные в команде add, должны существовать в текущем каталоге. Для того, чтобы добавить в репозиторий целое дерево каталогов, например, файлы, полученные от стороннего поставщика, используйте команду import. See section Команда import: импортировать исходные тексты.

Добавленные файлы не помещаются в репозиторий, пока вы не выполните команду commit, зафиксировав тем самым изменения. Выполнение команды add для файла, который был удален командой remove, отменит действие remove, если после нее еще не была выполнена команда commit. See section Удаление файлов, там находится пример.

Ключ командной строки `-k' задает способ по умолчанию, которым будут извлекаться файлы, дальнейшая информация находится в section Подстановка ключевых слов.

Ключ командной строки `-m' задает описание файла. Описание появляется в журнале истории, если разрешено его использование, see section Файл history. Также это описание будет сохранено в репозитории, когда файл будет зафиксирован. Команда log показывает это описание. Описание может быть изменено с помощью команды admin -t. See section Команда admin: администрирование. Если вы опустите флаг `-m описание', то у вас не спросят описания, а будет использована пустая строка.

Например, нижеследующие команды добавляют файл `backend.c' в репозиторий: $ cvs add backend.c $ cvs commit -m "Early version. Not yet compilable." backend.c

Когда вы добавляете файл, он добавляется только на ту ветку, над которой вы работаете (see section Создание ветвей и слияние). Вы можете позднее поместить добавления на другую ветку, если захотите (see section При слиянии можно добавлять и удалять файлы).

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

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

Доступ к репозиторию только для чтения

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

Пользователь, имеющий доступ к репозиторию только для чтения, может выполнять все команды CVS, не изменяющие репозиторий, за исключением определенных "административных" файлов (таких, как файлы блокировок и файл истории). Может потребоваться использовать эту возможность совместно с возможностью использования псевдонимов пользователей (see section Настройка сервера для парольной аутентификации).

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

Есть два способа указать доступ пользователя только для чтения: включающий и исключающий.

Включающий способ означает, что пользователь явно указывается в файле `$CVSROOT/CVSROOT/readers', в котором просто перечисляются "в столбик" пользователи. Вот пример: melissa splotnik jrandom

(Не забудьте символ новой строки в конце файла.)

Исключающий способ означает, что все, кто имеет доступ к репозиторию для записи, перечисляются в файле `$CVSROOT/CVSROOT/writers'. Если этот файл существует, то все пользователи, не упомянутые в нем, получают доступ только для чтения (конечно, даже пользователи только для чтения должны быть упомянуты в файле `CVSROOT/passwd'). Файл `writers' имеет тот же формат, что и файл `readers'.

Замечание: если ваш файл `CVSROOT/passwd' отображает пользователей CVS в системных пользователей (see section Настройка сервера для парольной аутентификации), убедитесь, что вы предоставляете или не предоставляете доступ только для чтения пользователям CVS, а не системным пользователям. Это означает, что в файлах `readers' и `writers' должны находиться пользователи CVS, которые могут не совпадать с системными пользователями.

Вот полное описание поведения сервера, принимающему решение, какой тип доступа предоставить:

Если файл `readers' существует, и данный пользователь не упомянут в нем, он получает доступ только для чтения. Если существует файл `writers', и этот пользователь НЕ упомянут в нем, то он также получает доступ только для чтения (это так даже если файл `readers' существует, но пользователь не упомянут в нем). В противном случае пользователь получает полный доступ для чтения и записи.

Конечно, возможен конфликт, если пользователь упомянут в обоих файлах. Такой конфликт разрешается консервативно и такой пользователь получает доступ только для чтения.

Доступ к веткам

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

Для того, чтобы извлечь ветку из репозитория, выполните команду `checkout' с ключом командной строки `-r', с именем метки в качестве параметра (see section Создание ветви). $ cvs checkout -r rel-1-0-patches tc

Если у вас уже есть рабочая копия, вы можете переключить ее на нужную ветку с помощью `update -r': $ cvs update -r rel-1-0-patches tc

или, что то же самое: $ cd tc $ cvs update -r rel-1-0-patches

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

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

Чтобы узнать, на какой ветви находится рабочая копия, можно использовать команду `status'. В том, что она вывела на экран, обратите внимание на поле, которое называется `Sticky tag' (see section Липкие метки) -- здесь CVS сообщает, на какой ветви находятся рабочие файлы: $ cvs status -v driver.c backend.c =================================================================== File: driver.c Status: Up-to-date Version: 1.7 Sat Dec 5 18:25:54 1992 RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v Sticky Tag: rel-1-0-patches (branch: 1.7.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: rel-1-0-patches (branch: 1.7.2) rel-1-0 (revision: 1.7) =================================================================== 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: rel-1-0-patches (branch: 1.4.2) Sticky Date: (none) Sticky Options: (none) Existing Tags: rel-1-0-patches (branch: 1.4.2) rel-1-0 (revision: 1.4) rel-0-4 (revision: 1.4)

Не смущайтесь тем, что номера ветвей для каждого файла различны (`1.7.2' и `1.4.2', соответственно). Метка ветви одна и та же, `rel-1-0-patches', и все файлы действительно находятся на одной и той же ветке. Номера лишь отражают точку в истории файла, в которой появилась ветвь. Из вышеприведенного примера можно узнать, что `driver.c' претерпел больше изменений, чем `backend.c', перед тем, как была создана ветка.

Смотри section Ветки и ревизии за деталями построения номеров ветвей.

Другие распространенные проблемы

Вот список проблем, не попадающих ни в одну из вышеперечисленных категорий. Если вы используете CVS 1.9.18 или раньше, и cvs update обнаруживает конфликт и пытается слить изменения, как описано в section Пример конфликта, но не сообщает вам, где именно присутствуют конфликты, значит, вы используете старую версию RCS. Самым простым решением, вероятно, будет обновить версию CVS до той, которая не нуждается во внешних программах RCS.

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

Файл `commitinfo'

Файл `commitinfo' описывает программы, которые выполняются перед тем, как команда `cvs commit' выполняет свою работу. Эти программы используются перед фиксированием изменений для проверки, чтоы измененный, добавленные и удаленные файлы действительно готовы к фиксированию. Это можно использовать, например, чтобы убедиться, что измененные файлы соответствуют стандартам кодирования, принятым в вашей организации.

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

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

Если имя репозитория не соответствует ни одному регулярному выражению в этом файле, то используется строка `DEFAULT', если она есть.

Помимо совпадающих строк, используются также все строки, начинающиеся с `ALL'.

Замечание: когда CVS обращается к сетевому репозиторию, `commitinfo' будет выполняться на сервере, а не на клиенте (see section Сетевые репозитории).

Файл `cvswrappers'

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

Ключ `-m' задает метод объединения, который нужно использовать при обновлении не-двоичного файла. `MERGE' означает обычное поведение CVS: попробовать объединить файлы. `COPY' означает, что cvs update откажется объединять файлы, точно так же, как это происходит с двоичными файлами, описанными с помощью ключа `-kb' (если файл описан как двоичный, то использовать `-m 'COPY'' необязательно). CVS предоставит пользователю две версии файлов, и потребует вручную внести необходимые изменения, пользуясь внешними по отношению к CVS инструментами. Предупреждение: не используйте `COPY' с CVS версии 1.9 и раньше -- они просто перезапишут один файл поверх другого, уничтожая старое содержимое. Ключ `-m' влияет только на поведение при обновлении, не затрагивая способ хранения файла. См. section Обработка двоичных файлов, где описана работа с ними.

В основном формат файла `cvswrappers' таков: маска_файла [ключ значение][ключ значение]...

где ключ -- это -m способ обновления (`MERGE' или `COPY') -k способ подстановки ключевых слов (See section Подстановка ключевых слов).

а значение заключено в одиночные кавычки.

Например, нижеследующая команда импортирует каталог, считая файлы, заканчивающиеся на `.exe', двоичными: cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag

Файл `editinfo'

ЗАМЕЧАНИЕ: использование `editinfo' устарело. Для задания редактора журнальных записей по умолчанию используйте переменную окружения EDITOR (see section Все переменные окружения, используемые в CVS) или глобальный ключ `-e' (see section Глобальные ключи командной строки) См. section Проверка журнальных записей, где описано, как использовать `verifymsg'.

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

Если в файле `editinfo' не найдено совпадающей строки, используется редактор, заданный переменной окружения $CVSEDITOR. Если эта переменная не установлена, используется переменная окружения $EDITOR. Если и эта переменная не установлена, используется редактор по умолчанию (См. section Фиксирование изменений).

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

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

Следует заметить, что ключевое слово `ALL' не поддерживается. Если совпадает более одной строки, используется первая. Это полезно для задания скрипта редактирования по умолчанию, а затем переопределения его в подкаталоге.

Если имя каталога в репозитории не совпадает ни с одним регулярным выражением в этом файле, то используется строка `DEFAULT', если она есть.

Если скрипт редактирования завершается с ненулевым кодом завершения, то процесс фиксирования аварийно завершается.

Заметьте, что когда CVS обращается к сетевому репозиторию, или когда используются ключи `-m' и `-F' команды cvs commit, то файл `editinfo' не используется. Вместо него можно использовать `verifymsg'.

Файл history

Файл `$CVSROOT/CVSROOT/history' используется для журналирования информации для команды history (see section Команда history: показать состояние файлов и пользователей). Для того, чтобы включить журналирование, этот файл следует создать. Это происходит автоматически при выполнении команды cvs init, которая используется для инициализации репозитория (see section Создание репозитория).

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

Файл конфигурации CVSROOT/config

Административный файл `config' содержит различные настройки, влияющие на поведение CVS. Синтаксис этого файла слегка отличается от синтаксиса прочих файлов. Переменные не подстанавливаются. Строки, начинающиеся с `#', считаются комментариями.

Все прочие строки состоят из ключевого слова, символа `=' и значения. Заметьте, что этот синтаксис очень строг. Дополнительные пробелы и символы табуляции не допускаются.

В настоящий момент определены следующие ключевые слова: RCSBIN=bindir Для CVS версий от 1.9.12 до 1.9.18, это ключевое слово указывало, что следует искать программы RCS в каталоге bindir. Современные версии CVS не требуют программ RCS; для совместимости эта установка допускается, но ничего не делает. SystemAuth=value Если value равно `yes', то pserver должен искать пользователя в системной базе данных пользователей, если он не найден в `CVSROOT/passwd'. Если же значение равно `no', то все пользователи сервера с парольной аутентификацией должны существовать в `CVSROOT/passwd'. По умолчанию значение равно `yes'. Дополнительная информация о pserver находится в section Прямое соединение с парольной аутентификацией. PreservePermissions=value Включить поддержку для хранения в репозитории специальных файлов устройств, символических ссылок, прав доступа к файлами и информации об их владельцах. Значение по умолчанию: `no'. See section Специальные файлы, где описаны подробности использования этого ключевого слова. TopLevelAdmin=value Изменить поведение команды `checkout' так, чтобы она создавала каталог `CVS/' на уровень выше вашего рабочего каталога, вдобавок к каталогам `CVS/', которые создаются внутри извлеченных каталогов. Значение по умолчанию -- `no'. Эта опция полезна, если вы обнаружите, что выполняете многие команды в каталоге на уровень выше вашего рабочий каталога, а не в одном из извлеченных подкаталогов. Каталог `CVS/', созданный таким образом, позволяет не указывать `CVSROOT' при каждой команде. Обеспечивается также место для файла `CVS/Template' (see section Как данные хранятся в рабочем каталоге). LockDir=directory Создавать файлы блокировок CVS в каталоге directory, а не в репозитории. Это полезно, если вы хотите разрешить пользователям читать из репозитория, предоставив им доступ на запись только в directory, а не в репозиторий. Вам нужно создать directory, а CVS сама создаст там требуемые подкаталоги. Информация о блокировках CVS находится в главе section Совместный доступ нескольких разработчиков к CVS. Перед включением опции `LockDir' убедитесь, что вы не используете ни одной копии CVS версий 1.9 или раньше, которые не поддерживают `LockDir', и не дадут об этом никакого предупреждения. Если позволить такому случиться, то некоторые пользователи CVS будут делать блокировки в одном каталоге, а другие -- в другом, и репозиторий может быть испорчен. CVS 1.10 не поддерживает `LockDir', но выдаст предупреждение, если использовать его на репозитории с включенным `LockDir'.

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

Файл loginfo

Файл `loginfo' используется для управления тем, куда посылается журнальная информация при выполнении `cvs commit'. В левой части строки находится регулярное выражение, с которым совпадает имя каталога, в котором производится изменение, относительно $CVSROOT. Остаток соответствующей строки -- это программа-фильтр, которая получает журнальное сообщение на стандартный ввод.

Если имя в репозитории не совпадает ни с одним регулярным выражением, используется строка `DEFAULT', если она есть.

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

Используется первое совпадающее регулярное выражение.

See section Выполнение программ на разных стадиях фиксирования, где описан синтаксис файла `loginfo'.

Пользователь может использовать в имени команды форматные строки. Такие строки состоят из символа `%', за которым следует пробел, одиночный форматный символ или набор форматных символов, заключенных в скобки `{' и `}'. Форматные символы таковы: s имя файла V старый номер ревизии (перед фиксированием) v новый номер ревизии (после фиксирования)

Все прочие символы, появляющиеся в форматной строке, превращаются в пустые строки (запятые, разделяющие их, сохраняются).

Например, можно использовать форматные строки `%', `%s', `%{s}' и `%{sVv}'.

На выходе образуется строка токенов, разделенных пробелами. Для обратной совместимости первый токен -- это имя репозитория, остальные -- список запрошенных в форматной строке полей, разделенных запятыми. Например, если репозиторий находится в `/u/src/master', форматная строка `%{sVv}', а были изменены три файла, (`ChangeLog', `Makefile' и `foo.c'), то на выходе появится /u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13

В качестве другого примера: `%{}' означает, что на выходе появится только имя репозитория.

Замечание: когда CVS обращается к сетевому репозиторию, то `loginfo' будет исполнен на стороне сервера, а не на стороне клиента (see section Сетевые репозитории).

Файл `modules'

В файле `modules' находится описание модулей, то есть коллекций исходных текстов. Файл модулей можно редактировать обычным для административных файлов способом.

Файл `modules' может содержать пустые строки и комментарии (строки, начинающиеся с `#'), а также описания модулей. Длинные описания можно разбивать на несколько строк, используя обратную косую черту (`\') в качестве последнего символа в строке.

Существует три основных типа модулей: модули-синонимы, обычные модули и амперсенд-модули. Разница между ними заключается в способе сопоставления файлов в репозитории файлам в рабочем каталоге. В нижеприведенных примерах в репозитории находится каталог `first-dir/', содержащий два файла, `file1' и `file2', а также каталог `sdir/'. `first-dir/sdir/' содержит также файл `sfile'.

Файл rcsinfo

Файл `rcsinfo' может использоваться, чтобы задать форму, которая редактируется при заполнении журнала фиксирований. Файл `rcsinfo' имеет синтаксис, подобный синтаксису файлов `verifymsg', `commitinfo' и `loginfo'. See section Обычный синтаксис. В отличие от остальных файлов, правая часть строки является не шаблоном команды, но полным именем файла, содержащего шаблон журнального сообщения.

Если имя в репозитории не соответствует ни одному регулярному выражению в этом файле, используется строка `DEFAULT', если она есть.

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

Шаблон журнального сообщения будет использоваться по умолчанию. Если вы зададите журнальное сообщение с помощью `cvs commit -m message' или `cvs commit -f file', то вместо шаблона будет использоватсья именно оно.

See section Проверка журнальных записей, где приведен пример файла `rcsinfo'.

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

Фиксирование изменений

После того, как вы проверили, что компилятор все еще компилируется, вы решили создать новую версию `backend.c'. При этом в репозитории появится ваш новый `backend.c', который станет доступным всем, использующим этот репозиторий. $ cvs commit backend.c

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

Переменная окружения $CVSEDITOR определяет, какой именно редактор будет вызван. Если $CVSEDITOR не установлена, то используется $EDITOR, если она, в свою очередь, установлена. Если обе переменные не установлены, используется редактор по умолчанию для вашей операционной системы, например, vi под UNIX или notepad для Windows 95/NT.

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

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

Если вы хотите избежать запуска редактора, укажите журнальную запись в командной строке, используя флаг `-m', например: $ cvs commit -m "Добавлена фаза оптимизации" backend.c

Флаги модулей

Описание обычных и амперсенд-модулей может содержать флаги, предоставляющие дополнительную информацию о модуле. -d name Дать рабочему каталогу другое имя, отличающееся от имени модуля. -e prog Задает программу prog, которая выполняется при экспорте модуля. prog выполняется с единственным аргументом, именем модуля. -i prog Задает программу prog, которая выполняется, когда изменения в файлах модуля помещаются в репозиторий. prog выполняется с полным именем соответствующего каталога (??? а не файла?) в репозитории. Файлы `commitinfo', `loginfo' и `verifymsg' обеспечивают дополнительные способы выполнения программ при фиксировании. -o prog Задает программу prog, которая выполняется, когда файлы модуля извлекаются в рабочий каталог. prog выполняется с единственным аргументом, именем модуля. -s status Задает статус модуля. Когда файл модулей выдается на экран с помощью `cvs checkout -s', модули в нем отсортированы по статусу, а затем по имени модуля. Этот ключ не имеет какого-либо другого значения. Этот ключ можно использовать для нескольких вещей, помимо статуса модуля: например, перечислить людей, ответственных за модуль. -t prog Задает программу prog, которая выполняется, когда файлы в модуле помечаются с помощью команды rtag. prog выполняется с двумя аргументами: именем модуля и именем метки, указанной в команде rtag. Эта программа не выполняется, когда дается команда tag. Обычно лучше использовать файл `taginfo' (see section Настройка журналирования). -u prog Задает програму, которая выполняется, когда команда `cvs update', выполняется в основном каталоге извлеченного модуля. prog выполняется с единственным аргументом, полным путем к указанному модулю в репозитории.

Где хранятся файлы в репозитории

Общая структура репозитория -- это дерево каталогов, соответствующее каталогам в рабочей копии. Предположим, например, что репозиторий находится в /usr/local/cvsroot

Вот возможное дерево каталогов (показаны только каталоги): /usr | +--local | | | +--cvsroot | | | | | +--CVSROOT | (административные файлы) | +--gnu | | | +--diff | | (исходный текст GNU diff) | | | +--rcs | | (исходный текст RCS) | | | +--cvs | (исходный текст CVS) | +--yoyodyne | +--tc | | | +--man | | | +--testing | +--(другое программное обеспечение фирмы Yoyodyne)

Внутри каталогов находятся файлы истории для каждого файла, находящегося под контролем версий. Имя файла истории -- это имя соответствующего файла с добавленным в конце `,v'. Вот как выглядит дерево каталогов для `yoyodyne/tc': $CVSROOT | +--yoyodyne | | | +--tc | | | +--Makefile,v +--backend.c,v +--driver.c,v +--frontend.c,v +--parser.c,v +--man | | | +--tc.1,v | +--testing | +--testpgm.t,v +--test2.t,v

Файл истории содержит, помимо всего прочего, достаточно информации, чтобы воссоздать любую редакцию файла, журнал всех зафиксированных изменений и имена всех пользователей, сделавших эти изменения. Файлы истории известны как RCS-файлы, потому что первой программой, которая создавала файлы этого формата, была система контроля версий RCS. Полное описание формата файлов находится на странице руководства rcsfile(5), распространяемого вместе с RCS, или в файле `doc/RCSFILES' в комплекте исходных текстов CVS. Этот формат файла используется повсеместно -- множество других программ могут по меньшей мере импортировать файлы этого формата.

Файлы RCS, используемые в CVS, отличаются от стандартного формата в нескольких местах. Наличие волшебных веток -- Самое большое отличие; смотри section Волшебные номера веток. Имена меток, которые позволяет использовать CVS, являются подмножеством тех, что позволены в RCS; смотри главу section Метки ревизий.

Глобальные ключи командной строки

Вот список имеющихся ключей командной строки CVS (те из них, что задаются слева от имени команды): --allow-root=rootdir Задает разрешенный каталог CVSROOT. См. section Настройка сервера для парольной аутентификации. -a Аутентифицировать всё общение между клиентом и сервером. Влияет только на клиента. В настоящее время это реализуется только при использовании соединения GSSAPI (see section Прямое соединение с использованием GSSAPI). Аутентификация предотвращает определённые виды атак, использующих перехват TCP-соединения. Включение аутентификации не включает шифрование. -b bindir В CVS 1.9.18 и более старых версиях этот ключ задавал каталог, в котором находятся программы RCS. Текущие версии CVS не выполняют программ RCS; этот ключ оставлен только для обратной совместимости. -T tempdir Использовать tempdir в качестве каталога, в котором расположены временные файлы. Переопределяет содержимое переменной среды $TMPDIR и каталог, заданный при компиляции. Этот параметр должен задавать полный путь. -d cvs_root_directory Использовать cvs_root_directory в качестве корневого каталога репозитория. Переопределяет содержимое переменной окружения $CVSROOT. See section Репозиторий. -e editor Использовать editor, чтобы ввести журнальное сообщение. Переопределяет содержимое переменных окружения $CVSEDITOR и $EDITOR. За дальнейшей информацией обращайтесь к section Фиксирование изменений. -f Не читать файл `~/.cvsrc'. Этот ключ чаще всего используется из-за неортогональности набора ключей CVS. Например, команда `cvs log' имеет ключ `-N' (отключить отображение имен меток), но не имеет соответствующего ключа, чтобы включить такое отображение. Поэтому если у вас в файле `~/.cvsrc' для команды `log' имеется ключ `-N', вам может потребоваться `-f', чтобы отобразить имена меток. -H --help Выдать информацию об указанной команде CVS (но не выполнять её). Если вы не укажете имя команды, то `cvs -H' выдаёт общую информацию об использовании CVS, включая список других ключей помощи. -l Выполнить команду, не журналируя её в файле истории команд.
See section Команда history: показать состояние файлов и пользователей. -n Не изменять ничего на диске. Попытаться выполнить команду CVS, но только выдавать отчёт; не удалять, обновлять или объединять существующие файлы, не создавать новых. Заметьте, что CVS не обязательно выдаст те же самые сообщения, что и без использования `-n', потому что в некоторых случаях CVS пропустит часть работы. -Q Команда вообще не будет выдавать сообщений, за исключением сообщений о серьезных проблемах. -q Команда будет выдавать только некоторые сообщения; например, информация о продвижении по дереву каталогов выдаваться не будет. -r Делать новые рабочие файлы доступными только для чтения. Тот же самый эффект достигается установкой переменной окружения $CVSREAD (see section Все переменные окружения, используемые в CVS). По умолчанию рабочие файлы создаются доступными для записи, если только не включено слежение (see section Слежение за чужими исходными текстами). -s variable=value Установить переменную пользователя (see section Подстановки в административных файлах). -t Отслеживать выполнение программы; отображать сообщения, сопровождающие различные шаги CVS. Особенно полезно совместно с `-n', чтобы изучить работу незнакомой команды. -v --version Отображает версию CVS и информацию об авторских правах. -w Делает новые рабочие файлы доступными для чтения и записи. Переопределяет содержимое переменной окружения $CVSREAD. Файлы по умолчанию создаются для чтения и записи, если только не был установлен $CVSREAD или же не использовался ключ `-r'. -x Шифровать всё взаимодействие между клиентом и сервером. Воздействует только на клиента CVS. В текущей версии реализовано только при использовании соединения с GSSAPI (see section Прямое соединение с использованием GSSAPI) или соединения с Kerberos (see section Прямое соединение с помощью Kerberos). Включение шифрования подразумевает, что в канале связи будет также включена аутентификация. Поддержка шифрования по умолчанию недоступна; при компиляции CVS используйте специальный ключ командной строки к ./configure --enable-encryption. -z gzip-level Установить уровень компрессии.Влияет только на клиента CVS.

Игнорирование файлов с помощью cvsignore

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

CVS использует список файлов (или шаблонов файлов в стиле sh(1)), которые следует игнорировать при выполнении update, import и release. This list is constructed in the following way. Список инициализируется определенными шаблонами имен файлов: имена, служащие для служебных целей CVS и других распространенных систем контроля версий; обычные имена файлов с заплатами, объектных и архивных файлов, а также резервных копий файлов, создаваемых текстовыми редакторами. Остальные имена -- побочные продукты деятельности разнообразных утилит. В настоящее время стандартный список шаблонов игнорируемых файлов таков: RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core Список игнорируемых файлов для каждого репозитория находится в `$CVSROOT/CVSROOT/cvsignore' и добавляется к общему списку, если этот файл существует. Список игнорируемых файлов для каждого пользователя находится в домашнем каталоге пользователя в файле `~/.cvsignore' и добавляется к общему списку, если этот файл существует. Содержимое переменной окружения $CVSIGNORE добавляется к списку. Параметры ключей `-I' добавляются к списку. Когда CVS обходит дерево каталогов, к списку добавляется содержимое файлов `.cvsignore'. Шаблоны, находящиеся в файле `.cvsignore', используются только в соответствующем каталоге, но не в его подкаталогах.

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

Задание команде cvs import ключа `-I !' приведет к импорту всего, и обычно вы именно этого и хотите, когда импортируете дистрибутив исходных текстов, не содержащий ничего лишнего. Однако, глядя на вышеприведенные правила, можно заметить ложку дегтя в бочке меда: если в дистрибутиве находятся файлы `.cvsignore', то они будут обработаны, даже если в командной строке был указан `-I !'. Для того, чтобы импортировать абсолютно все файлы, единственным обходным маневром будет удалить файлы `.cvsignore'. Это уродливо, поэтому в будущем `-I !' может перестать обрабатывать файлы `.cvsignore'.

Заметьте, что синтаксис файла со списком игнорируемых файлов состоит из набора строк, каждая из которых содержит список файлов, разделенных пробелами. Таким образом, нет простого способа задать имена файлов, содержащие пробелы, но можно использовать шаблон `foo?bar', чтобы игнорировать файл `foo bar' (в этом случае, правда, будет также проигнорирован файл `fooxbar' и т. п._). Заметьте, также, что сейчас не существует способа поместить в этот файл комментарии.

Информация о том, кто следит и кто редактирует

Команда: cvs watchers [-lR] files ...

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

Ключи командной строки и список файлов обрабатываются так же, как и в команде cvs watch.

Команда: cvs editors [-lR] files ...

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

Список файлов и ключи командной строки обрабатываются точно так же, как и в команде cvs watch.

Информирование коллег о фиксировании ревизий

Часто бывает полезно информировать своих коллег, когда вы фиксируете новую ревизию файла. Можно использовать ключ `-i' в файле `modules' или файле `loginfo' для автоматизации этого процесса. See section Файл `modules'. See section Файл loginfo. Можно использовать эти возможности CVS для того, чтобы указать CVS, например, отсылать почтовые сообщения всем разработчикам или помещать сообщение в локальную группу новостей.

Исключение каталогов из списка

Модуль-синоним может исключить определенные каталоги из модулей, используя восклицательный знак (`!') перед именем каждого исключенного каталога.

Например, если файл `modules' содержит exmodule -a !first-dir/sdir first-dir

то при извлечении модуля `exmodule' будут извлечено все содержимое `first-dir/', кроме файлов из каталога `first-dir/sdir'.

Использование клиента с парольной аутентификацией

Перед соединением с сервером клиент должен зарегистрироваться с помощью команды cvs login. При регистрации на сервере проверяется пароль, который затем сохраняется для дальнейшего общения с сервером. Команда cvs login должна знать имя пользователя, имя машины с сервером и полный путь к репозиторию. Эту информацию CVS получает из ключа командной строки `-d' и переменной окружения CVSROOT.

cvs login -- это интерактивная команда, она спрашивает пароль: cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login CVS password:

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

После регистрации вы можете заставить CVS соединяться напрямую с сервером, используя при этом сохраненный пароль. cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo

Обязательно надо указать `:pserver:', в противном случае CVS будет считать, что ему следует использовать rsh для соединения с сервером (see section Соединение с помощью rsh). (Когда вы получили рабочий каталог и выполняете команды CVS внутри него, больше не требуется явно указывать репозиторий, потому что CVS запоминает его в подкаталоге `CVS' в рабочем каталоге.)

Пароли обычно хранятся в файле `$HOME/.cvspass'. У него читабельный формат, но не следует редактировать его, если вы не знаете точно, что вы делаете. Пароли не хранятся открытым текстом, а слегка шифруются, чтобы защититься от нечаянного нарушения безопасности (например, системный администратор, случайно заглянувший внутрь этого файла).

Пароль текущего сетевого репозитория удаляется из CVS_PASSFILE при использовании команды cvs logout.

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

Использование ключевых слов

Для того, чтобы поместить в файл ключевое слово, вы просто пишете в нём, например, $Id$, а затем фиксируете файл. CVS автоматически заменит ключевое слово во время операции фиксирования.

Обычной практикой является помещение строки $Id$ в исходные файлы, чтобы они оказались в файлах, созданных из исходных. Например, если вы управляете исходным кодом компьютерной программы, вы можете создать переменную, которая инициализируется этой строкой. Некоторые компиляторы языка C поддерживают директиву #pragma ident. Система управления документами может обеспечивать способ для передачи строки в сгенерированные файлы.

Команда ident, являющаяся частью пакета RCS, может использоваться для извлечения из файла ключевых слов и их значений. Это полезно для работы с текстовыми файлами, и особенно полезно для извлечения ключевых слов из двоичных файлов. $ ident samp.c samp.c: $Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $ $ gcc samp.c $ ident a.out a.out: $Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $

SCCS -- другая популярная система контроля ревизий. В её состав входит команда what, очень похожая на ident и использующаяся в тех же целях. Во многих местах, где не установлен RCS, стои SCCS. Так как what ищет последовательность символов @(#), то можно довольно просто вставлять ключевые слова, которые обнаруживаются обеими командами. Просто поместите перед ключевым словом RCS волшебную фразу SCCS, например: static char *id="@(#) $Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";

Использование параллельного cvs server для соединения

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

Для каждодневных операций вы, скорее всего, предпочтете :local: или :fork:, в зависимости от ваших предпочтений. Конечно, :fork: особенно полезен при тестировании и отладке cvs и сетевого протокола. Точнее, мы избавляемся от необходимости настройки сети, таймаутов, проблем с аутентификацией, свойственных сетевому доступа, но при этом пользуемся собственно сетевым протоколом.

Чтобы соединиться, используя метод доступа :fork:, добавьте его к имени локального репозитория, например: cvs -d :fork:/usr/local/cvsroot checkout foo

Как и при использовании :ext:, сервер по умолчанию называется `cvs'. Если установлена переменная окружения CVS_SERVER, используется ее значение.

Использование слежений со старыми версиями CVS

Если вы используете возможность слежения за репозиторием, то в нем создаются каталоги `CVS/', в которых хранится информация о слежениях за файлами из соответствующего каталога. Если вы попытаетесь использовать в этом репозитории CVS версии 1.6 и ранее, вы получите такое сообщение об ошибке: cvs update: cannot open CVS/Entries for reading: No such file or directory

Выполняемая команда, скорее всего, будет прервана. Для использования возможности слежения обновите все копии CVS, которые используют этот репозиторий в локальном или серверном режиме. Если вы не можете совершить обновление, используйте команды watch off и watch remove, чтобы удалить все слежения, а затем восстановите репозиторий в состояние, с которым может работать CVS 1.6.

Исправление ошибок

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

Извлечение свежей ревизии файла

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

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

Например, представим себе, что вы извлекли ревизию 1.4 и начали редактировать ее. В это время кто-то еще поместил в репозиторий ревизию 1.5 и, вскорости, ревизию 1.6. Если теперь вы выполните команду update, CVS внедрит изменения между ревизиями 1.4 и 1.6 в ваш файл.

Если изменения между ревизиями 1.4 и 1.6 случились слишком близко к вашим изменениям, происходит пересечение. В таких случаях на экран выдается предупреждение, а в результирующем файле оказываются обе версии пересекающихся строк, разделенные специальными маркерами. See section Команда update: обновить рабочий каталог из репозитория, где полностью описана команда update.

Как данные хранятся в рабочем каталоге

Пока мы описываем внутреннюю работу CVS, которая иногда становится видна, мы можем также поговорить о том, что CVS хранит в каталогах `CVS' в рабочих каталогах. Как и в случае с репозиторием, CVS обрабатывает эту информацию, и обычно вы обращаетесь к ней посредством команд CVS. В некоторых случаях, однако, бывает полезно напрямую работать с содержимым этих каталогов, например, в графической оболочке jCVS или пакете VC для emacs. Такие программы должны следовать рекомендациям в этой главе, если они желают нормально работать совместно с другими программами, использующими те же самые файлы, включая будущие их версии, а также с CVS, работающим из командной строки.

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

Файлы хранятся в текстовом формате, соответствующем соглашениям операционной системы. Это означает, что рабочие каталоги не переносимы между системами с разными форматами хранения текстовых файлов. Это сделано специально, исходя из того, что сами файлы, находящиеся под управлением CVS, вероятно, также не переносимы между такими платформами. `Root' Этот файл содержит текущий корневой каталог CVS, как описано в section Как сообщить CVS, где находится репозиторий. `Repository' Этот файл содержит каталог в репозитории, которому соответствует текущий каталог. Здесь может быть имя с полным или относительным путем; CVS способна обрабатывать оба варианта, начиная с версии 1.3. Относительный путь отсчитывается от корня, хотя использование абсолютного пути довольно распространено и программы должны уметь обрабатывать оба варианта. Например, после команды cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc `Root' будет содержать :local:/usr/local/cvsroot а `Repository' будет содержать или /usr/local/cvsroot/yoyodyne/tc или yoyodyne/tc Если рабочий каталог не имеет соответствующего каталога в репозитории, то `Repository' должен содержать `CVSROOT/Emptydir'. `Entries' В этом файле перечислены файлы и каталоги в рабочем каталоге.
Первый символ каждой строки указывает тип каждой строки. Если символ нераспознан, программа, читающая файл, должна спокойно пропустить эту строку, чтобы дать возможность развития в будущем. Если первый символ -- это `/', то формат строки таков If the first character is `/', then the format is: /имя/ревизия/метка времени[+конфликт]/опции/тэг или дата где `[' и `]' не являются частью строки, но указывают, что `+' и отметка о конфликте не обязательны. name --- это имя файла в каталоге. ревизия -- это номер ревизии, на которой основан файл в рабочем каталоге, или `0' для добавленного файла, или `-', за которым следует номер ревизии, для удаленного файла. метка времени -- это время, когда CVS создала этот файл; если это время отличается от текущего времени модификации файла, значит, он был изменен. Метка времени записывается в UTC (по гринвичу), в формате, используемом функцией стандарта ISO C asctime() (например, `Sun Apr 7 01:29:26 1996'). Можно написать также строку в другом формате, например, `Result of merge', чтобы указать, что файл всегда должен считаться измененным. Эта строка -- вовсе не специальный случай: чтобы узнать, изменился ли файл, CVS берет дату модификации файла и просто сравнивает строку со строкой метка времени. конфликт указывает, что произошел конфликт. Если эта строка совпадает с действительным временем модификации, значит, пользователь еще не справился с конфликтом. опции содержат прилипшие ключи командной строки (например, `-kb' для двоичных файлов). тэг или дата содержит либо `T', за которой следует имя тэга, либо `D', за которой следует прилипший тэг или дата. Заметьте, что если метка времени содержит пару меток времени, разделенных пробелом, а не единственную метку времени, значит, вы имеете дело с версией CVS ранее 1.5 (этот случай здесь не документирован). Если первый символ в строке в файле `Entries' -- это `D', это означает подкаталог. `D' на отдельной строке указывает, что программа, которая создала файл `Entries', умеет обращаться с подкаталогами (то есть, если такая строка присутствует, и нет других строк, начинающихся с `D', значит, подкаталогов нет).


В противном случае строка выглядит так: D/имя/заполнитель1/заполнитель2/заполнитель3/заполнитель4 где имя -- это имя подкаталога, а все поля заполнитель должны игнорироваться, в целях будущих расширений. Программы, изменяющие файлы `Entries', должны сохранять значения этих полей. Строки в файле `Entries' могут быть в любом порядке. `Entries.Log' В этом файле хранится та же самая информация, что и в файле `Entries', и с его помощью можно обновлять эту информацию без необходимости полностью переписывать файл `Entries', включая возможность сохранять информацию, даже если программа, писавшая в `Entries' и `Entries.Log' аварийно завершилась. Программы, читающие файл `Entries' должны также проверять существование файла `Entries.Log'. Если последний существует, то они должны прочесть файл `Entries' и внести в него изменения из файла `Entries.Log', после чего рекуомендуется записать заново файл `Entries' и удалить файл `Entries.Log'. Формат строки файла `Entries.Log' --- односимвольная команда, за которой следует строка, в формате `Entries'. Команда -- это либо `A' для указания, что строка добавляется, либо `R' -- если строка удаляется, или любой другой символ -- если эту строку следует проигнорировать (для будущих расширений). Если второй символ строки в файле `Entries.Log' -- не пробел, значит, файл был создан старой версией CVS (здесь не документируется). Программы, которые пишут, но не читают, могут спокойно игнорировать `Entries.Log'. `Entries.Backup' Это временный файл. Рекомендованное использование -- записать новый файл `Entries' в `Entries.Backup', затем переименовать его (атомарно, если возможно) в `Entries'. `Entries.Static' Единственная вещь, интересующая нас об этом файле -- существует он или нет. Если существует, это значит, что была получена только часть каталога и CVS не будет создавать в нем дополнительных файлов. Чтобы очистить этот файл, используйте команду update с опцией `-d', чтобы получить дополнительные файлы и удалить `Entries.Static'. `Tag' В этом файле находятся прилипшие тэги и даты для этого каталога.


Первый символ -- `T' для тэга ветки, `N' для обычного тэга или `D' для даты. Другие символы должны игнорироваться, для будущих расширений. За этим символом следует тэг илидата. Заметьте, что прилипшие тэги и даты применяются к добавляемым файлам; они могут отличаться от тэгов и дат, прилипших к отдельным файлам. Общая информация о прилипших тэгах и датах находится в section Липкие метки. `Checkin.prog' `Update.prog' В этих файлах хранятся имена программ, заданных опциями `-i' и `-u' в файле `modules', соответственно. `Notify' В этом файле хранятся уведомления (например, для edit или unedit), которые еще не было отосланы на сервер. Их формат еще не документирован здесь. `Notify.tmp' Этот файл по отношению к файлу `Notify' является тем же, что `Entries.Backup' по отношению к `Entries'. Чтобы создать файл `Notify', сначала запишите его новое содержимое в `Notify.tmp', затем (атомарно, если возможно), переименуйте его в `Notify'. `Base' Если используются слежения, то команда edit сохраняет исходную копию файла в каталоге `Base'. Это позволяет команде unedit работать, даже если нет доступа к серверу. `Baserev' В этом файле перечислены ревизии каждого файла в каталоге `Base'. Формат таков: Bимя/ревизия/расширение поле расширение должно быть проигнорировано, для будущих расширений. `Baserev.tmp' Этот файл по отношению к `Baserev' является тем же, чем `Entries.Backup' по отношению к `Entries'. Чтобы создать записать файл `Baserev', сначала запишите его новое содержимое в `Baserev.tmp', затем (атомарно, если возможно), переименуйте его в `Baserev'. `Template' Этот файл содержит шаблон, заданный файлом `rcsinfo' (see section Файл rcsinfo). Он используется только клиентом; не-клиент-серверные варианты CVS напрямую обращаются к `rcsinfo'.

Как данные хранятся в репозитории

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

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

---

---