• Обзор
  • Что такое CVS?
  • Чем не является CVS?
  • Пример работы с CVS
    • Получение исходного кода
    • Фиксирование изменений
    • Уборка за собой
    • Просмотр изменений
• Репозиторий
  • Как сообщить CVS, где находится репозиторий
  • Как данные хранятся в репозитории
    • Где хранятся файлы в репозитории
    • Права доступа к файлам
    • Специфические для Windows права доступа
    • Чердак
    • Каталог CVS в репозитории
    • Блокировки в репозитории
    • Как в каталоге CVSROOT хранятся файлы
  • Как данные хранятся в рабочем каталоге
  • Административные файлы
    • Редактирование административных файлов
  • Несколько репозиториев
  • Создание репозитория
  • Резервное копирование репозитория
  • Перемещение репозитория
  • Сетевые репозитории
    • Требования к серверу
    • Соединение с помощью rsh
    • Прямое соединение с парольной аутентификацией
      • Настройка сервера для парольной аутентификации
      • Использование клиента с парольной аутентификацией
      • Вопросы безопасности при парольной аутентификации
    • Прямое соединение с использованием GSSAPI
    • Прямое соединение с помощью Kerberos
    • Использование параллельного cvs server для соединения
  • Доступ к репозиторию только для чтения
  • Временные каталоги на сервере
• Начинаем проект под CVS
  • Помещение файлов в репозиторий
    • Создание дерева каталогов из нескольких файлов
    • Создание файлов из других систем контроля версий
    • Создание дерева каталогов с нуля
  • Определение модуля
• Ревизии
  • Номера ревизий
  • Версии и ревизии
  • Назначение номеров ревизий
  • Метки ревизий
  • Что пометить в рабочем каталоге
  • Как помечать по дате или ревизии
  • Удаление, перемещение и удаление меток
  • Пометки при добавлении и удалении файлов
  • Липкие метки
• Создание ветвей и слияние
  • Для чего хороши ветви?
  • Создание ветви
  • Доступ к веткам
  • Ветки и ревизии
  • Волшебные номера веток
  • Слияние веток
  • Многократное слияние из ветки
  • Слияние изменений между двумя ревизиями
  • При слиянии можно добавлять и удалять файлы
• Рекурсивное поведение
• Добавление, удаление и переименование файлов и каталогов
  • Добавление файлов в каталог
  • Удаление файлов
  • Удаление каталогов
  • Перемещение и переименование файлов
    • Обычный способ переименования
    • Перемещение файла с ревизиями
    • Копирование файла с ревизиями
  • Перемещение и переименование каталогов
• Просмотр истории
  • Журнальные записи
  • База истории
  • Настройка журналирования
  • Команда annotate
• Обработка двоичных файлов
  • Вопросы использования двоичных файлов
  • Как хранить двоичные файлы
• Несколько разработчиков
  • Статус файла
  • Извлечение свежей ревизии файла
  • Пример конфликта
  • Информирование коллег о фиксировании ревизий
  • Совместный доступ нескольких разработчиков к CVS
  • Как отследить, кто редактирует файлы?
    • Как с помощью CVS следить за определенными файлами?
    • CVS может посылать вам уведомления
    • Как редактировать файлы, за которыми наблюдают?
    • Информация о том, кто следит и кто редактирует
    • Использование слежений со старыми версиями CVS
  • Выбор между блокированными и неблокированными извлечениями
• Управление ревизиями
  • Когда фиксировать изменения?
• Подстановка ключевых слов
  • Список ключевых слов
  • Использование ключевых слов
  • Как избежать подстановки
  • Режимы подстановки
  • Проблемы с ключевым словом $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 и этом руководстве?
• Индекс

Обзор

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

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

Что такое 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 не является системой управления сборкой.

Несмотря на то, что структуры вашего репозитория и файла модулей взаимодействуют с системой управления сборкой (то есть файлами `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

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

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

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

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

$ cvs checkout tc

при этом будет создан каталог `tc', в который будут помещены все файлы с исходными текстами.

$ cd tc
$ ls
CVS Makefile backend.c driver.c frontend.c parser.c

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

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

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

После того, как вы проверили, что компилятор все еще компилируется, вы решили создать новую версию `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

Уборка за собой

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

$ cd ..
$ rm -r tc

но лучшим способом будет использование команды release (see section Команда release: сообщить, что модуль более не используется):

$ cd ..
$ cvs release -d tc
M driver.c
? tc
You have [1] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': n
** `release' aborted by user choice.

Команда release проверяет, что все ваши изменения были зафиксированы. Если включено журналирование истории, то в файле истории появляется соответствующая пометка. See section Файл history.

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

В вышеприведенном примере команда release выдала несколько строк. `? tc' означает, что файл `tc' неизвестен CVS. Беспокоиться не о чем, `tc' -- это исполняемый файл компилятора, и его не следует хранить в репозитории. See section Игнорирование файлов с помощью cvsignore за информацией о том, как избежать этого предупреждения. See section Сообщения команды release за полной информацией о возможных сообщениях команды release.

`M driver.c' -- более серьезное сообщение. Оно означает, что файл `driver.c' был изменен с момента последнего получения из репозитория.

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

Вы решаете перестраховаться и отвечаете n RET, когда release просит подтверждения.

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

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

$ cd tc
$ cvs diff driver.c

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

$ cvs commit -m "Добавлена фаза оптимизации" driver.c
Checking in driver.c;
/usr/local/cvsroot/tc/driver.c,v <-- driver.c
new revision: 1.2; previous revision: 1.1
done
$ cd ..
$ cvs release -d tc
? tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': y

Репозиторий

Репозиторий в CVS хранит полные копии всех файлов и каталогов, находящихся под контролем версий.

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

CVS может обращаться к репозиторию большим количеством способов. Репозиторий может находиться на локальной машине, на соседней машине или на машине, находящейся на другом континенте. Чтобы различать пути доступа к репозиториям, их имена начинаются с метода доступа. Например, метод доступа `:local:' означает, что репозиторий находится в локальном каталоге, то есть `:local:/usr/local/cvsroot' означает, что репозиторий находится в `/usr/local/cvsroot' на компьютере, на котором используется CVS. Другие методы доступа описаны в section Сетевые репозитории.

Если метод доступа не указан, и имя репозитория не содержит `:', то предполагается метод :local:. Если в имени содержится `:', то предполагается метод доступа :ext: или :server:. Например, если ваш локальный репозиторий находится в `/usr/local/cvsroot', то вы можете использовать /usr/local/cvsroot вместо :local:/usr/local/cvsroot. Но если, например, под Windows NT ваш локальный репозиторий находится в `c:\src\cvsroot', то вы должны указать метод доступа, то есть :local:c:\src\cvsroot.

Репозиторий делится на две части. `$CVSROOT/CVSROOT' содержит административные файлы CVS. Все прочие каталоги содержат модули, определенные пользователем.

Как сообщить CVS, где находится репозиторий

Существует несколько способов сообщить CVS, где искать репозиторий. Вы можете явно задать репозиторий в командной строке с помощью опции -d ("directory", каталог):

cvs -d /usr/local/cvsroot checkout yoyodyne/tc

Другим вариантом является установка переменной окружения $CVSROOT в полный путь до корня репозитория, например, `/usr/local/cvsroot'. Чтобы установить $CVSROOT, пользователи csh и tcsh должны поместить в свой файл `.cshrc' или `.tcshrc' такую строку:

setenv CVSROOT /usr/local/cvsroot

Пользователи sh и bash должны поместить в свой файл `.profile' или `.bashrc' такие строки

CVSROOT=/usr/local/cvsroot
export CVSROOT

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

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

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

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

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

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

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

/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 Метки ревизий.

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

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

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

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

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

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

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

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

При использовании pserver обычно требуются гораздо более жесткие права доступа к каталогу CVSROOT и каталогам, находящимся в CVSROOT; see section Настройка сервера для парольной аутентификации.

Некоторые операционные системы позволяют определенным программам выполнять операции, которые не может выполнять тот, кто вызывает эти программы. Например, возможности setuid или setgid в UNIX или установленные образы в VMS. CVS не разрабатывался, чтобы использовать такие возможности, и поэтому попытки установить CVS таким образом обеспечат защиту только лишь от случайных ошибок; те, кто желает обойти защиту, смогут это сделать и, в зависимости от конкретных условий, смогут получить доступ еще куда-либо помимо CVS. Вы можете попробовать использовать pserver. Эта возможность также способна дать ложное чувство безопасности или открыть дыру, больше чем та, которую вы пытаетесь закрыть, поэтому внимательно прочтите документацию на безопасность pserver, если вы собираетесь его использовать (section Настройка сервера для парольной аутентификации).

Специфические для Windows права доступа

Некоторые вопросы, связанные с правами доступа, специфичны для операционных систем класса Window (Windows 95/98, Windows NT и, скорее всего, будущие подобные операционные системы. Часть нижесказанного может быть применима к OS/2, хотя я не уверен).

Чердак

Вы заметите, что иногда 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/fileattr'); смотри `fileattr.h' среди исходных текстов CVS за дополнительной информацией. В будущем в этом каталоге могут оказать другие дополнительные файлы, поэтому сегодняшние реализации должны игнорировать неизвестные файлы.

Это поведение реализовано только в версиях CVS 1.7 и выше, смотри section Использование слежений со старыми версиями CVS.

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

Видимое пользователем поведение блокировок 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, где находится дополнительное обсуждение и мотивация.

Как в каталоге CVSROOT хранятся файлы

Каталог `$CVSROOT/CVSROOT' содержит различные административные файлы. В каком-то смысле этот каталог подобен любому другому каталогу в репозитории; он содержит RCS-файлы, чьи имена заканчиваются на `,v', и многие команды CVS оперируют с ними обычным образом. Однако, имеется несколько различий.

Для каждого административного файла, в дополнение к RCS-файлу, хранится его последняя ревизия. Например, есть RCS-файл `loginfo,v' и файл `loginfo', содержащий последнюю ревизию, находящуюся в `loginfo,v'. Когда вы фиксируете административный файл, CVS должен написать:

cvs commit: Rebuilding administrative file database

и обновить его извлеченную копию в `$CVSROOT/CVSROOT'. Если это не так, значит, что-то случилось с CVS (see section Что делать с ошибками в CVS и этом руководстве?). Чтобы ваши CVS обращался с вашими собственными файлами точно так же, вы можете добавить их имена в административный файл `checkoutlist'.

По умолчанию, файл `modules' ведет себя как описано выше. Если же он становится очень большим, то хранение в виде плоского файла может привести к медленному поиску модулей (я не уверен, что это все еще столь же важно, как и тогда, когда эта возможность впервые появилась; я не видел расчетов быстродействия). Таким образом, внеся определенные изменения в исходный код CVS, можно хранить файл модулей в базе данных, которая имеет интерфейс с ndbm, например, Berkeley db или GDBM. Если эта опция используется, то база данных модулей будет храниться в файлах `modules.db', `modules.pag' и/или `modules.dir'.

Информация о назначении разнообразных административных файлов находится в section Справочник по административным файлам.

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

Пока мы описываем внутреннюю работу 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'.

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

Каталог `$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'.

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

Административные файлы можно редактировать точно так же, как и любой другой модуль. Используйте `cvs checkout CVSROOT', чтобы получить рабочий каталог, редактируйте его и зафиксируйте изменения обычным образом.

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

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

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

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

cvs -d server1:/cvs co dir1
cd dir1
cvs -d server2:/root co sdir
cvs update

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

Создание репозитория

Чтобы настроить CVS-репозиторий, сначала выберите машину и диск, на котором будет храниться история ревизий исходных текстов. Требования к процессору и памяти умеренны, поэтому подойдет практически любая машина. Детали описаны в section Требования к серверу.

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

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

Чтобы создать репозиторий, выполните команду cvs init. Она создаст пустой репозиторий в корневом каталоге CVS, заданном обычным образом (see section Репозиторий). Например,

cvs -d /usr/local/cvsroot init

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

cvs init включит журналирование истории; если вы не хотите этого, удалите файл истории после выполнения cvs init. See section Файл history.

Резервное копирование репозитория

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

Во-первых, с параноидальной точки зрения, следует либо не использовать CVS во время резервного копирования, либо сделать так, чтобы программа резервного копирования блокировала репозиторий в процессе. Чтобы не использовать CVS, вы можете запретить логины на машины, которые могут иметь доступ к репозиторию, отключить CVS-сервер или сделать что-либо подобное. Детали зависят от вашей операционной системы и от настройки CVS. Чтобы заблокировать CVS, создайте файлы блокировок (`#cvs.rfl') в каждом каталоге репозитория. См. section Совместный доступ нескольких разработчиков к CVS за дополнительной информацией о блокировках CVS. Даже учитывая вышесказанное, если вы просто скопируете файлы, ничего особенно страшного не произойдет. Однако, при восстановлении из резервной копии репозиторий может находиться в неустойчивом состоянии, что, впрочем, нетрудно исправить вручную.

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

• Получите новый рабочий каталог.
• Скопируйте файлы из рабочего каталога, сделанного перед аварией, поверх файлов в новом рабочем каталоге (не копируйте содержимое каталогов `CVS').
• Работая в новом рабочем каталоге, используйте команды типа cvs update и cvs diff, чтобы выяснить, что изменилось, а затем зафиксируйте изменения в репозиторий.

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

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

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

Сетевые репозитории

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

:метод:пользователь@машина:/путь/к/репозиторию

Детали зависят от того, как вы соединяетесь с сервером.

Если метод не указан, а имя репозитория содержит `:', то метод по умолчанию -- ext или server, в зависимости от платформы; оба метода описаны в section Соединение с помощью rsh.

Требования к серверу

Простой ответ: требования к серверу умеренны -- если дерево каталогов не очень большое, и активность не слишком высока, то подойдет машина с 32Mb памяти или даже меньше.

В реальной жизни, конечно, все сложнее. Оценка пикового использования памяти достаточна, чтобы оценить общие требования. Здесь документированы две такие области максимального потребления памяти; все остальные по сравнению с ними незначительны (если вы обнаружите, что это не так, дайте нам знать, как описано в section Что делать с ошибками в CVS и этом руководстве?, чтобы мы обновили документацию.

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

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

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

Потребление ресурсов для клиентской машины еще более умеренны -- любая машина, способная выполнять соответствующую операционную систему, будет пригодна.

Информация о требованиях к дисковому пространству находится в section Создание репозитория.

Соединение с помощью rsh

CVS использует протокол rsh для работы с сетевым репозиторием, поэтому на сетевой машине должен быть создан файл `.rhosts', позволяющий доступ данному пользователю.

Например, предположим, что вы пользователь `mozart' на локальной машине `toe.example.com', а сервер находится на `faun.example.com'. На машине `faun' поместите в файл `.rhosts' в домашнем каталоге пользователя `bach' следующее:

toe.example.com mozart

Потом протестируйте, что rsh работает, запустив

rsh -l bach faun.example.org 'echo $PATH'

Затем вам следует убедиться, что rsh найдет сервер. Убедитесь, что путь, напечатанный в результате выполнения этого примера содержит каталог, содержащий исполняемый файл `cvs', который является серверной версией CVS. Вы можете установить путь в `.bashrc', `.cshrc', и т. п., но не в файлах `.login' или `.profile'. Можно также установить переменную среды CVS_SERVER на клиентской машине, чтобы указать, какой исполняемый файл вы хотите использовать, например, `/usr/local/bin/cvs-1.6'.

Не требуется редактировать `inetd.conf', чтобы запустить CVS как демона.

Вы можете использовать в CVSROOT два метода доступа для rsh. :server: задает использование внутреннего клиента rsh, который поддерживается только в некоторых портах CVS. :ext: указывает внешнюю программу rsh. По умолчанию это rsh, но вы можете установить переменную среды CVS_RSH, чтобы выполнять другую программу, которая может соединиться с сервером (например, remsh на HP-UX 9, потому что rsh немного отличается. Эта программа должна уметь пересылать данные с сервера и на сервер, не изменяя их; например, rsh из Windows NT не подходит, потому что он транслирует CR-LF в LF. Порт CVS для OS/2 содержит хэк, который передает rsh параметр `-b', чтобы обойти это,но так как это может привести к проблемам с программами, не являющимися стандартным rsh, это может быть изменено в будущем. Если вы устанавливаете CVS_RSH в ssh или какую-нибудь другую замену rsh, то инструкции по настройке `.rhosts', скорее всего, неприменимы, поэтому обратитесь к документации по соответствующей программе.

Продолжая наш пример, предположив, что вы хотите обратиться к модулю `foo' в репозитории `/usr/local/cvsroot' на машине `faun.example.org', вы набираете:

cvs -d :ext:bach@faun.example.org:/usr/local/cvsroot checkout foo

(Можно не писать `bach@', если имена пользователей совпадают на локальной и сетевой машинах.)

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

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

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

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

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

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

Если ваш inetd позволяет использование номеров портов в `/etc/inetd.conf', то можно использовать такую строку:

2401 stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/usr/cvsroot pserver

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

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

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

cvspserver 2401/tcp

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

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

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

bach:ULtgRLXo7NRxs
cwang:1sOp854gDF3DY

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

При парольной аутентификации сервер сначала проверяет, находится ли пользователь в файле `CVSROOT/passwd'. Если нет, или файл `CVSROOT/passwd' не существует, то сервер пытается проверить пароль, используя системную процедуру проверки пользователя (это может быть запрещено, установив SystemAuth=no в файле конфигурации, see section Файл конфигурации CVSROOT/config). При использовании файла `CVSROOT/passwd' сервер выполняется с правами пользователя, указанного в третьем поле соответствующей строки, или, если третьего поля нет, то в первом (таким образом CVS позволяет использовать ненастоящие имена пользователей, если в `CVSROOT/passwd' заданы соответствующие им настоящие системные имена. В любом случае, CVS не получит дополнительных прав, кроме тех, что уже имеет пользователь.

С помощью файла `CVSROOT/passwd' можно также отобразить пользователей CVS в имена пользователей машины, добавив двоеточие и системное имя пользователя после пароля. Например:

cvs:ULtgRLXo7NRxs:kfogel
generic:1sOp854gDF3DY:spwang
anyone:1sOp854gDF3DY:spwang

Таким образом, пользователи, обращающиеся по сети к репозиторию на faun.example.org, используя команду

cvs -d :pserver:cvs@faun.example.org:/usr/local/cvsroot checkout foo

будут работать с сервером, который имеет права пользователя kfogel, если, конечно, они успешно аутентифицировались. При этом сетевые пользователи не знают системный пароль пользователя kfogel, потому что файл `CVSROOT/passwd' может содержать другой пароль, используемый только CVS-сервером. Как показано в вышеприведенном примере, можно отображать разные имена пользователей CVS в единственного системного пользователя.

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

В настоящее время единственный способ поместить пароль в `CVSROOT/passwd' -- это вырезать его откуда-нибудь еще. Когда-нибудь появится команда cvs passwd. В отличие от других файлов в `$CVSROOT/CVSROOT', вы редактируете файл `CVSROOT/passwd' напрямую, а не с помощью CVS.

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

Перед соединением с сервером клиент должен зарегистрироваться с помощью команды cvs 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 не смогут найти пароля для пересылки его на сервер.

Вопросы безопасности при парольной аутентификации

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

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

Заметьте, что из-за того, что каталог `$CVSROOT/CVSROOT' содержит `passwd' и прочие файлы, использующиеся в целях безопасности, нужно следить за правами доступа к этому каталогу так же хорошо, как из правами доступа к `/etc'. То же самое применимо к самому каталогу `$CVSROOT' и любому каталогу, находящему в нем. Кто угодно, получив доступ для записи в этот каталог, сможет стать любым пользователем в системе. Заметьте, что эти права доступа обычно строже при использовании pserver.

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

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

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

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

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

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

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

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

Для соединения с использованием GSSAPI, используйте `:gserver:'. Например,

cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo

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

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

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

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

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

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

Когда вы захотите использовать CVS, сначала, как обычно, получите билет (kinit); этот билет должен позволять вам зарегистрироваться на сервере. Затем

cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo

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

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

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

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

Чтобы соединиться, используя метод доступа :fork:, добавьте его к имени локального репозитория, например:

cvs -d :fork:/usr/local/cvsroot checkout foo

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

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

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

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

Временные каталоги на сервере

В процессе работы CVS-сервер создает временные каталоги. Они называются

cvs-servpid

где pid -- это номер процесса сервера. Они находятся в каталоге, указанном в переменной окружения TMPDIR (see section Все переменные окружения, используемые в CVS), ключом командной строки `-T' или в `/tmp' по умолчанию.

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

• если сервер аварийно завершается из-за внутренней ошибки, он может оставить временный каталог, чтобы облегчить отладку;
• если сервер был убит так, что не смог убрать за собой (например, `kill -KILL' под UNIX);
• система прекращает свою работу, не сообщив предварительно серверу об этом факте.

В таких случаях вы должны вручную удалить каталоги `cvs-servpid'. Если нет сервера с номером процесса pid, то сделать это можно совершенно безопасно.

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

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

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

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

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

Создание дерева каталогов из нескольких файлов

Когда вы начнете использовать CVS, вы, скорее всего, уже имеете несколько проектов, которые можно поместить под контроль CVS. В этих случаях самым простым методом будет использование команды import. Самым простым объяснением, вероятно, будет привести пример. Если файлы, которые вы хотите поместить под CVS, находятся в `wdir', а вы хотите, чтобы они появились в репозитории в каталоге `$CVSROOT/yoyodyne/rdir', вы можете сказать:

$ cd wdir
$ cvs import -m "Imported sources" yoyodyne/rdir yoyo start

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

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

$ cd ..
$ mv dir dir.orig
$ cvs checkout yoyodyne/dir # объяснение следует
$ diff -r dir.orig yoyodyne/dir
$ rm -r dir.orig

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

Команда checkout получает в качестве аргумента имя модуля (как в предыдущих примерах) или имя каталога относительно $CVSROOT, как в вышеприведенном примере.

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

Если какие-то из файлов, которые нужно импортировать, являются бинарными, вам потребуется использовать обертки, чтобы указать, какие именно. See section Файл `cvswrappers'.

Создание файлов из других систем контроля версий

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

Из RCS

Если вы использовали RCS, найдите все RCS-файлы, обычно файлу `foo.c' будет соответствовать файл `RCS/foo.c,v' (этот файл может также находиться в другом месте, обратитесь к документации на RCS. Затем создайте соответствующие каталоги в CVS, если они еще не существуют. Затем скопируйте файл в соответствующие каталоги в репозитории (имя в репозитории должно совпадать с именем исходного файла с добавленным `,v'; файлы находятся прямо в соответствующем каталоге репозитория, а не в подкаталоге `RCS/'. Это --- один из редких случаев, когда желателен прямой доступ к репозиторию, без использования команд CVS. Теперь вы можете извлечь новый рабочий каталог. RCS-файл не должен быть заблокирован, когда вы перемещаете его под управление CVS, иначе у CVS будут проблемы при работе с этим файлом.

Из другой системы контроля версий

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

Из SCCS

В каталоге `contrib/' среди исходных текстов CVS есть скрипт `sccs2rcs', конвертирующий файлы SCCS в файлы RCS. Замечание: вы должны выполнить этот скрипт на машине, на которой установлен как SCCS, так и RCS, и этот скрипт не поддерживается.

Из PVCS

В каталоге `contrib/' среди исходных текстов CVS есть скрипт `pvcs_to_rcs', конвертирующий архивы PVCS в файлы RCS. Вы должны выполнить этот скрипт на машине, на которой установлены как PVCS, так и RCS, и как и все прочее в каталоге `contrib/', этот скрипт не поддерживается. Детали описаны в комментариях к скрипту.

Создание дерева каталогов с нуля

Для нового проекта самоым простым способом, вероятно, будет создать пустую структуру каталогов, например:

$ mkdir tc
$ mkdir tc/man
$ mkdir tc/testing

Затем используйте команду import, чтобы создать соответствующую (пустую) структуру каталогов внутри репозитория:

$ cd tc
$ cvs import -m "Created directory structure" yoyodyne/dir yoyo start

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

Убедитесь, что права доступа, которые CVS дает новым каталогам в `$CVSROOT', правильны.

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

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

В простых случаях нижеследующих шагов достаточно для определения модуля.

1. извлеките рабочую копию файла `modules':

   $ cvs checkout CVSROOT/modules
   $ cd CVSROOT
   

2. отредактируйте этот файл, вставив в него строку, определяющую модуль. См. See section Административные файлы. See section Файл `modules' за полным описанием файла `modules'. Например, для описания модуля `tc' можно использовать такую строку:

   tc yoyodyne/tc
   

3. зафиксируйте ваши изменения в файле `modules'

   $ cvs commit -m "Added the tc module." modules
   

4. Освободите модуль CVSROOT.

   $ cd ..
   $ cvs release -d CVSROOT
   

Ревизии

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

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

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

Каждая ревизия файла имеет уникальный номер ревизии. Номера ревизий выглядят как `1.1', `1.2', `1.3.2.2' или даже `1.3.2.2.4.5'. Номер ревизии всегда содержит четное количество десятичных чисел, разделенных точкой. По умолчанию ревизия 1.1 -- первая ревизия файла. В номере каждой следующей ревизии самая правая цифра увеличивается на единицу. Вот пример нескольких ревизий, новые версии находятся правее старых:

 +-----+ +-----+ +-----+ +-----+ +-----+
 ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 +-----+ +-----+ +-----+ +-----+ +-----+

Может также оказаться, что в номерах ревизий будет больше одной точки, например, `1.3.2.2'. Такие номера означают ревизии, находящиеся на ветках (see section Создание ветвей и слияние); эти номера подробно описаны в section Ветки и ревизии.

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

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

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

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

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

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

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

$ cvs commit -r 3.0

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

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

Номера ревизий живут своей собственной жизнью. Они могут совершенно никак не соотноситься с номером версии вашего программного продукта. В зависимости от того, как вы используете CVS, номера ревизий могут измениться несколько раз между двумя выпусками продукта. Например, файлы с исходными текстами RCS 5.6 имеют такие номера ревизий:

ci.c 5.21
co.c 5.9
ident.c 5.3
rcs.c 5.12
rcsbase.h 5.11
rcsdiff.c 5.10
rcsedit.c 5.11
rcsfcmp.c 5.9
rcsgen.c 5.10
rcslex.c 5.11
rcsmap.c 5.2
rcsutil.c 5.10

Вы можете использовать команду tag, чтобы задать буквенное имя определенной ревизии файла. Вы можете использовать ключ командной строки `-v' команды status, чтобы увидеть все метки, которые имеет файл, а также какие номера ревизий они представляют. Имена меток должны начинаться с буквы и могут содержать буквы, цифры и знаки `-' и `_'. Два имени меток BASE и HEAD зарезервированы для использования в CVS. Предполагается, что будущие зарезервированные имена будут иметь специальный вид, например, начинаться с символа `.', чтобы избежать конфликтов с действительными именами меток.

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

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

$ cvs tag rel-0-4 backend.c
T backend.c
$ cvs status -v backend.c
===================================================================
File: backend.c Status: Up-to-date

 Version: 1.4 Tue Dec 1 14:39:01 1992
 RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v
 Sticky Tag: (none)
 Sticky Date: (none)
 Sticky Options: (none)

 Existing Tags:
 rel-0-4 (revision: 1.4)

Полный синтаксис команды cvs tag, включая разнообразные ключи командной строки, описан в section Краткий справочник по командам CVS.

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

$ cvs tag rel-1-0 .
cvs tag: Tagging .
T Makefile
T backend.c
T driver.c
T frontend.c
T parser.c

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

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

$ cvs checkout -r rel-1-0 tc

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

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

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

 file1 file2 file3 file4 file5

 1.1 1.1 1.1 1.1 /--1.1* <-*- TAG
 1.2*- 1.2 1.2 -1.2*-
 1.3 \- 1.3*- 1.3 / 1.3
 1.4 \ 1.4 / 1.4
 \-1.5*- 1.5
 1.6

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

 file1 file2 file3 file4 file5

 1.1
 1.2
 1.1 1.3 _
 1.1 1.2 1.4 1.1 /
 1.2*----1.3*----1.5*----1.2*----1.1 (--- <--- Look here
 1.3 1.6 1.3 \_
 1.4 1.4
 1.5

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

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

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

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

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

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

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

-D дата

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

-f

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

-r метка

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

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

cvs tag -r 1.4 backend.c

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

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

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

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

cvs rtag -d rel-0-4 tc

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

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

cvs tag -r 1.6 -F stable backend.c

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

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

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

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

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

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

Липкие метки

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

В большинстве случаев липкость -- это запутанный аспект CVS, о котором вам не следует думать. Однако, даже если вы не желаете использовать эту возможность, вы все же захотите что-нибудь узнать о липких метках (например, как их избежать!).

Можно использовать команду status, чтобы посмотреть, какие установлены липкие метки или даты:

$ cvs status driver.c
===================================================================
File: driver.c Status: Up-to-date

 Version: 1.7.2.1 Sat Dec 5 19:35:03 1992
 RCS Version: 1.7.2.1 /u/cvsroot/yoyodyne/tc/driver.c,v
 Sticky Tag: rel-1-0-patches (branch: 1.7.2)
 Sticky Date: (none)
 Sticky Options: (none)

Липкие метки остаются на ваших рабочих файлах до тех пор, пока вы не удалите их с помощью `cvs update -A'. Опция `-A' извлекает версию файла из головной ревизии ствола и забывает обо всех липких метках, датах и ключах командной строки.

Самое распространенное использование липких меток -- указать, над какой ветвью идет работа, что описано в section Доступ к веткам. Однако, липкие метки также используются и без веток. Предположим, например, что вы хотите избежать обновления вашего рабочего каталога, чтобы защититься от изменений, которые делают ваши коллеги. Вы, конечно, можете просто не выполнять команду cvs update. Если же вы хотите избежать обновления только части большого дерева, то липкие метки могут помочь. Если вы извлечете определенную ревизию, скажем, 1.4, то она станет липкой. Последующие команды cvs update не станут извлекать последнюю ревизию до тех пор, пока вы не очистите метку с помощью cvs update -A. Точно так же, использование ключа командной строки `-D' команд update и checkout задает липкую дату, которая используется для будущих извлечений.

Люди часто хотят извлечь старую версию файла без установки липкой метки. Это можно сделать с помощью ключа командной строки `-p' команд checkout или update, которая посылает содержимое файла на стандартный вывод. Например:

$ cvs update -p -r 1.1 file1 >file1
===================================================================
Checking out file1
RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
VERS: 1.1
***************
$

Однако, это не самый простой способ, если вы спрашиваете, как отменить последнее фиксирование (в этом примере -- поместить `file1' обратно в то состояние, в котором он был в ревизии 1.1). В этом случае лучше будет использовать ключ командной строки `-j' команды update; дальнейшее обсуждение находится в section Слияние изменений между двумя ревизиями.

Создание ветвей и слияние

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

Позже вы можете переместить изменения с одной ветки на другую или же с ветки в ствол, это называется слиянием. Сначала выполняется cvs update -j, чтобы слить изменения в рабочий каталог, а затем эти изменения фиксируются, что приводит к копированию изменения в другую ветку.

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

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

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

Создание ветви

Вы можете создать ветвь, используя tag -b. Например, предполагая, что вы находитесь в каталоге с рабочей копией:

$ cvs tag -b rel-1-0-patches

Это отщепляет ветку, основанную на текущей ревизии рабочей копии, и присваивает этой ветке имя `rel-1-0-patches'.

Важно понимать, что ветки создаются в репозитории, а не в рабочей копии. Создание ветки, основанной на текущей ревизии, как в вышеприведенном примере, НЕ переключает рабочую копию на использование ветки (как сделать это -- описано в section Доступ к веткам).

Можно также создать ветку вообще без использования рабочей копии, используя rtag.

$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc

`-r rel-1-0' означает, что эта ветка имеет корневую ревизию, соответствующую метке `rel-1-0'. Это не обязательно должна быть самая последняя ревизия: довольно часто бывает полезно отщепить ветку от старой ревизии (например, для исправления ошибки в старой версии, которая в основном стабильна).

Как и в случае с `tag', ключ командной строки `-b' заставляет rtag создать ветку (а не алфавитное имя ревизии). Заметьте, что номера ревизий, соответствующих `rel-1-0', скорее всего, будут различаться от файла к файлу.

Таким образом, полный эффект этой команды -- создать новую ветку, которая называется `rel-1-0-patches', в модуле `tc', которая растет в дереве ревизий из точки, помеченной как `rel-1-0'.

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

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

Для того, чтобы извлечь ветку из репозитория, выполните команду `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 Ветки и ревизии за деталями построения номеров ветвей.

Ветки и ревизии

Обычно история ревизий файла -- это линейная возрастающая последовательность номеров (see section Номера ревизий):

 +-----+ +-----+ +-----+ +-----+ +-----+
 ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
 +-----+ +-----+ +-----+ +-----+ +-----+

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

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

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

 +-------------+
 Branch 1.2.2.3.2 -> ! 1.2.2.3.2.1 !
 / +-------------+
 /
 /
 +---------+ +---------+ +---------+
Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 / +---------+ +---------+ +---------+
 /
 /
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
 !
 !
 ! +---------+ +---------+ +---------+
Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
 +---------+ +---------+ +---------+

Обычно не требуется задумываться о точных деталях того, как строятся номера веток, но вот еще подробности: когда CVS создает номер ветки, он берет первое неиспользованное четное число, начиная с двойки. Поэтому, если вы хотите создать ветку от ревизии 6.4, она будет называться 6.4.2. Номера веток, заканчивающиеся на ноль (например, 6.4.0), используются для внутренних нужд CVS (see section Волшебные номера веток). Ветка 1.1.1 имеет специальное значение. See section Слежение за чужими исходными текстами.

Волшебные номера веток

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

Номера веток состоят из нечетного количества десятичных целых, разделенных точками. See section Номера ревизий. Однако же, это не полная правда. Из соображений эффективности CVS иногда вставляет лишний ноль во вторую справа позицию (1.2.4 становится 1.2.0.4, а 8.9.10.11.12 становится 8.9.10.11.0.12 и так далее).

CVS довольно хорошо прячет такие "волшебные" ветки, но в нескольких местах ему это не удается:

• Номера волшебных веток появляются в выдаче cvs log.
• Вы не можете указать символическое имя ветки в команде cvs admin.

Можно использовать команду admin, чтобы переназначить символическое имя ветки на то, которое ожидает увидеть CVS. Например, если R4patches присвоено ветке 1.4.2 (волшебный номер 1.4.0.2) в файле `numbers.c', можно сделать так:

$ cvs admin -NR4patches:1.4.2 numbers.c

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

Слияние веток

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

Ключ командной строки `-j' означает "объединить" (join).

Представьте себе такое дерево ревизий:

+-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- основной ствол
+-----+ +-----+ +-----+ +-----+
 !
 !
 ! +---------+ +---------+
 Ветвь R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 +---------+ +---------+

Ветке 1.2.2 была назначена метка (символическое имя) `R1fix'. В нижеследующем примере предполагается, что модуль `mod' содержит единственный файл, `m.c'.

$ cvs checkout mod # Извлчеь последнюю ревизию, 1.4

$ cvs update -j R1fix m.c # Слить все изменения, сделанные на ветке,
 # т. е. изменения между ревизиями 1.2
 # и 1.2.2.2, в рабочую копию файла

$ cvs commit -m "Included R1fix" # создать ревизию 1.5.

В результате операции слияния может произойти конфликт. В это случае вам сначала надо справиться с ним перед фиксированием изменений. See section Пример конфликта.

Команда checkout также поддерживает флаг `-j ветка'. Можно добиться эффекта, обсуждавшегося выше, с помощью

$ cvs checkout -j R1fix mod
$ cvs commit -m "Добавлен R1fix" 

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

Мы продолжаем обсуждение примера. Теперь дерево ревизий выглядит так:

+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- ствол
+-----+ +-----+ +-----+ +-----+ +-----+
 ! *
 ! *
 ! +---------+ +---------+
 Ветвь R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
 +---------+ +---------+

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

Предположим теперь, что разработка ветки `R1fix' продолжается:

+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- ствол
+-----+ +-----+ +-----+ +-----+ +-----+
 ! *
 ! *
 ! +---------+ +---------+ +---------+
 Ветвь R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
 +---------+ +---------+ +---------+

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

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

cvs update -j 1.2.2.2 -j R1fix m.c # Слить изменения между 1.2.2.2 и
 # головой ветки R1fix

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

cvs update -j R1fix:yesterday -j R1fix m.c

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

cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c

Слияние изменений между двумя ревизиями

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

Команда

$ cvs update -j 1.5 -j 1.3 backend.c

отменит изменения, сделанные между ревизиями 1.3 и 1.5. Обратите внимание на порядок указания ревизий!

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

Указав два ключа командной строки `-j', можно также отменить удаления и добавления файлов. Например, предположим, у вас есть файл `file1', существовавший в ревизии 1.1. Затем вы удалили его, создав "мертвую" ревизию 1.2. Теперь предположим, что вы хотите добавить его опять, с тем же самым содержимым, что он имел ранее. Вот как сделать это:

$ cvs update -j 1.2 -j 1.1 file1
U file1
$ cvs commit -m test
Checking in file1;
/tmp/cvs-sanity/cvsroot/first-dir/file1,v <-- file1
new revision: 1.3; previous revision: 1.2
done
$

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

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

For example:

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

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

Рекурсивное поведение

Почти все подкоманды CVS работают рекурсивно, если вы укажете в качестве аргумента каталог. Например, представим себе такую структуру каталогов:

 $HOME
 |
 +--tc
 | |
 +--CVS
 | (служебные файлы CVS)
 +--Makefile
 +--backend.c
 +--driver.c
 +--frontend.c
 +--parser.c
 +--man
 | |
 | +--CVS
 | | (служебные файлы CVS)
 | +--tc.1
 |
 +--testing
 |
 +--CVS
 | (служебные файлы CVS)
 +--testpgm.t
 +--test2.t

Если `tc' -- это текущий рабочий каталог, то верны следующие утверждения:

• `cvs update testing' эквивалентно

  cvs update testing/testpgm.t testing/test2.t
  

• `cvs update testing man' обновляет все файлы в подкаталогах
• `cvs update .' или просто `cvs update' обновляет все файлы в каталоге tc

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

Рекурсивное поведение подкоманд CVS может быть отключено с помощью ключа командной строки `-l', и наоборот, ключ командной строки `-R' может использоваться для принудительной рекурсии, если `-l' был указан в `~/.cvsrc' (see section Ключи по умолчанию и файл ~/.cvsrc).

$ cvs update -l # Не обновлять файлы в подкаталогах

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

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

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

Для того, чтобы добавить новый файл в каталог, совершите следующие шаги:

• Сначала у вас должна быть рабочая копия каталога. 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 При слиянии можно добавлять и удалять файлы).

Удаление файлов

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

Вот как можно удалить файл, сохранив доступ к его старым ревизиям:

• Убедитесь, что у вас неизмененная версия этого файла. See section Просмотр изменений, там описан один из способов убедиться в этом. Можно также использовать команды status или update. Если вы удалите файл без предварительной фиксации изменений, вы, конечно же, не сможете извлечь этот файл в том виде, в котором он находился перед удалением.
• Удалите файл из рабочей копии каталога. Например, можно использовать программу rm.
• Выполните `cvs remove имя-файла', чтобы сообщить CVS, что вы действительно хотите удалить этот файл.
• Выполните `cvs commit имя-файла', чтобы зафиксировать удаление файла в репозитории.

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

Команда: cvs remove [ключи] файлы ...

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

Вот пример удаления нескольких файлов:

$ cd test
$ rm *.c
$ cvs remove
cvs remove: Removing .
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files" cvs commit: Examining .
cvs commit: Committing .

Для удобства можно удалять файлы и одновременно делать cvs remove, используя ключ командной строки `-f'. Например, вышеприведенный пример можно переписать так:

$ cd test
$ cvs remove -f *.c
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files" cvs commit: Examining .
cvs commit: Committing .

Если вы выполните команду remove, а затем перемените свое решение, еще не зафиксировав удаление, то команду remove можно отменить с помощью команды add.

$ ls
CVS ja.h oj.c
$ rm oj.c
$ cvs remove oj.c
cvs remove: scheduling oj.c for removal
cvs remove: use 'cvs commit' to remove this file permanently
$ cvs add oj.c
U oj.c
cvs add: oj.c, version 1.1.1.1, resurrected

Если вы осознаете свою ошибку перед выполнением команды remove, можно использовать update, чтобы воскресить файлы:

$ rm oj.c
$ cvs update oj.c
cvs update: warning: oj.c was lost
U oj.c

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

Удаление каталогов

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

Можно удалить каталог, удалив все файлы в нем. Нет способа удалить сам каталог. Вместо этого вы задаете командам cvs update, cvs checkout или cvs export ключ командной строки `-P', который заставит CVS удалять пустые каталоги в рабочем каталоге. Вероятно, лучше всего будет всегда указывать `-P', если вы хотите, чтобы существовал пустой каталог, поместите в него пустой файл, например, `.keepme', чтобы не дать CVS с ключом `-P' удалить этот каталог.

Заметьте, что при использовании ключей `-r' или `-D' с командами checkout и export подразумевается также использование `-P'. При этом CVS сможет создать или не создавать каталог, в зависимости от того, находились ли в этом каталоге какие-либо файлы в конкретной версии проекта.

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

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

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

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

Обычным способом перемещения файла является копирование old в new, а затем выполнение команд CVS для удаления файла old из репозитория и добавления туда файла new.

$ mv old new
$ cvs remove old
$ cvs add new
$ cvs commit -m "old переименован в new" old new

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

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

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

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

$ cd $CVSROOT/dir
$ mv old,v new,v

Преимущества:

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

Недостатки:

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

Копирование файла с ревизиями

Этот способ также требует прямых изменений репозитория. Он безопасен, но не без подводных камней.

# Копировать RCS-файл в репозитории 
$ cd $CVSROOT/dir
$ cp old,v new,v
# Удалить старый файл 
$ cd ~/dir
$ rm old
$ cvs remove old
$ cvs commit old
# Удалить все метки из new
$ cvs update new
$ cvs log new # Запомнить все метки, не являющиеся именами веток
$ cvs tag -d tag1 new
$ cvs tag -d tag2 new
...

Удалив метки, вы сможете извлекать старые ревизии

Преимущества:

• Извлечение старых ревизий работает корректно, если вы используете для извлечения ревизий ключ командной строки `-rметка', а не `-Dдата'.
• Журнал изменений остается в целости и сохранности.
• Номера ревизий не искажаются.

Недостатки:

• Нет способа легко увидеть историю файла до переименования.

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

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

Если вам действительно нужно возиться с репозиторием, чтобы переименовать или удалить каталог в репозитории, вы можете сделать это так:

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

   $ cd $CVSROOT/родительский-каталог
   $ mv старый-каталог новый-каталог
   

3. Исправьте административные файлы CVS, если это требуется (например, если вы переименовали целый модуль).
4. Сообщите всем, что они могут извлечь свои рабочии копии опять и продолжить работу.

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

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

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

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

Журнальные записи

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

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

База истории

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

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

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

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

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

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

ALL /usr/local/cvsroot/CVSROOT/loggit

Здесь `/usr/local/cvsroot/CVSROOT/loggit' является таким скриптом:

#!/bin/sh
echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog

Команда annotate

Команда: cvs annotate [-flR] [-r rev|-D date] files ...

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

$ cvs annotate ssfile
Annotations for ssfile
***************
1.1 (mary 27-Mar-96): ssfile line 1
1.2 (joe 28-Mar-96): ssfile line 2

В файле `ssfile' в настоящий момент содержит две строки. Строка ssfile line 1 была зафиксирована mary двадцать седьмого марта. Затем, двадцать восьмого, joe добавил строки ssfile line 2, не изменяя строки ssfile line 1. В этом отчете ничего не сказано о том, что было удалено или заменено; используйте cvs diff, чтобы узнать это (see section Команда diff: показать различия между ревизиями).

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

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

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

Вопросы использования двоичных файлов

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

Одной из основных функций контроля версий -- просмотр различий между двумя ревизиями. Например, если кто-то еще создает новую ревизию файла, то вам хотелось бы взглянуть на то, что изменилось и выяснить, верно ли были сделаны изменения. Для текстовых файлов CVS обспечивает такую функциональность с помощью команды cvs diff. Для двоичных файлов можно извлечь две ревизии и сравнить их с помощью внешнего инструмента (например, в текстовых процессорах обычно имеется такая возможность. Если такого инструмента не существует, нужно отслеживать изменения посредством с помощью других механизмов, например, заставляя людей писать хорошие журнальные сообщения, надеясь при этом, что они действительно сделали то, что намеревались сделать.

Другая возможность системы контроля версий -- объединение двух ревизий. Для CVS это происходит в двух контекстах. Во-первых, пользователи редактируют файлы в различных рабочих каталогах (see section Несколько разработчиков). Во-вторых, объединения совершаются явно, используя команду `update -j' (see section Создание ветвей и слияние).

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

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

Как хранить двоичные файлы

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

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

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

Вот пример создания нового файла с использование флага `-kb':

$ echo '$Id$' > kotest
$ cvs add -kb -m"A test file" kotest
$ cvs ci -m"Первое фиксирование; файл содержит ключевое слово" kotest

Если файл случайно будет добавлен без `-kb', можно использовать команду cvs admin для восстановления. Например,

$ echo '$Id$' > kotest
$ cvs add -m"A test file" kotest
$ cvs commit -m"Первое фиксирование; содержит ключевое слово" kotest
$ cvs admin -kb kotest
$ cvs update -A kotest
# Для не-UNIX систем:
# Скопировать откуда-нибудь хорошую копию файла
$ cvs commit -m "Сделать файл двоичным" kotest

Когда вы извлечете файл `kotest', он не станет двоичным, потому что вы не зафиксировали его как двоичный. Команда cvs admin -kb устанавливает метод подстановки ключевых слов по умолчанию для этого файла, но не изменяет рабочую копию файла, которая у вас есть. Если вам нужно справиться с символами конца строки (при использовании CVS на не-UNIX системах), вам требуется зафиксировать новую копию файла, как показано выше в команде cvs commit. Под UNIX достаточно выполнить cvs update -A.

Однако, используя cvs admin -k для изменения режима подстановки ключевых слов, знайте, что этот режим не подчиняется контролю версий. Это означает, что если, скажем, в старых версиях пакета какой-то файл был текстовым, а затем в новых версиях появился двоичный файл с тем же именем, то CVS не обеспечивает способа извлечь файл в двоичном или текстовом режиме в зависимости от версии пакета, которую вы извлекаете. Для обхода этой проблемы хорошего решения не существует.

Вы можете установить значения по умолчанию, которые используют команды cvs add и cvs import, для выяснения, является ли файл текстовым или двоичным, основываясь на его имени. Например, можно гарантировать, что файлы, чьи имена заканчиваются на `.exe' являются двоичными. See section Файл `cvswrappers'. В настоящий момент нет способа для определения, является ли файл текстовым или двоичным, в зависимости от его содержимого. Основная трудность при разработке такой возможности --- неясно, как различить такие файлы, потому что способы сильно различаются в разных операционных системах.

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

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

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

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

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

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

Статус файла

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

Up-to-date

Файл идентичен последней ревизии в репозитории, находящейся на используемой ветке.

Locally Modified

Вы редактировали этот файл и еще не зафиксировали изменения.

Locally Added

Вы добавили этот файл с помощью cvs add, и еще не зафиксировали изменения.

Locally Removed

Вы удалили файл с помощью cvs remove и еще не зафиксировали изменения.

Needs Checkout

Кто-то еще поместил новую ревизию в репозиторий. Название немного сбивает с толку, потому что требуется использовать команду cvs update, а не cvs checkout, чтобы получить свежайшую версию.

Needs Patch

Похоже на "Needs Checkout", но CVS-сервер пошлет заплату, а не целый файл. В принципе это приведет к тому же самому результату.

Needs Merge

Кто-то еще поместил новую ревизию в репозиторий, а вы также изменили этот файл.

File had conflicts on merge

Похоже на "Locally Modified", только последняя выполненная команда cvs update обнаружила конфликт. Если вы еще не исправили его, сделайте это, как описано в section Пример конфликта.

Unknown

CVS ничего не знает об этом файле. Например, вы создали новый файл и еще не выполнили cvs add.

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

Ключи команды status перечислены в section Краткий справочник по командам CVS. Информация о Sticky tag и Sticky date находится в section Липкие метки. Информация о Sticky options находится в описании флага `-k' в section Ключи команды update.

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

$ cvs -n -q update

Ключ командной строки `-n' указывает не выполнять обновление, а просто сообщить о состоянии файлов; `-q' не печатает имена каждого каталога. Прочуя информацию о команде update можно найти в section Краткий справочник по командам 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.

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

Предположим, что ревизия 1.4 файла `driver.c' содержит такой код:

#include <stdio.h>

void main()
{
 parse();
 if (nerr == 0)
 gencode();
 else
 fprintf(stderr, "No code generated.\n");
 exit(nerr == 0 ? 0 : 1);
}

Ревизия 1.6 файла `driver.c' содержит такой код:

#include <stdio.h>

int main(int argc,
 char **argv)
{
 parse();
 if (argc != 1)
 {
 fprintf(stderr, "tc: No args expected.\n");
 exit(1);
 }
 if (nerr == 0)
 gencode();
 else
 fprintf(stderr, "No code generated.\n");
 exit(!!nerr);
}

Ваша рабочая копия файла `driver.c', основанная на ревизии 1.4, перед выполнением `cvs update' содержит такой код:

#include <stdlib.h>
#include <stdio.h>

void main()
{
 init_scanner();
 parse();
 if (nerr == 0)
 gencode();
 else
 fprintf(stderr, "No code generated.\n");
 exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

Вы выполняете `cvs update':

$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c

CVS сообщает, что вы встретились с конфликтами. Ваш исходный рабочий файл сохранен в `.#driver.c.1.4'. Новая версия `driver.c' содержит такой код:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
 char **argv)
{
 init_scanner();
 parse();
 if (argc != 1)
 {
 fprintf(stderr, "tc: No args expected.\n");
 exit(1);
 }
 if (nerr == 0)
 gencode();
 else
 fprintf(stderr, "No code generated.\n");
<<<<<<< driver.c
 exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
=======
 exit(!!nerr);
>>>>>>> 1.6
}

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

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

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
 char **argv)
{
 init_scanner();
 parse();
 if (argc != 1)
 {
 fprintf(stderr, "tc: No args expected.\n");
 exit(1);
 }
 if (nerr == 0)
 gencode();
 else
 fprintf(stderr, "No code generated.\n");
 exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

Теперь вы можете поместить этот файл в репозиторий в качестве ревизии 1.7.

$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
new revision: 1.7; previous revision: 1.6
done

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

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

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

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

Совместный доступ нескольких разработчиков к CVS

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

[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo

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

Заметьте, что эти блокировки предназначаются для защиты внутренних структур данных CVS и не имеют никакого отношения к слову блокировка в том смысле, который используется в RCS и означает блокированные извлечения (see section Несколько разработчиков).

Неограниченное количество пользователей может одновременно читать репозиторий; только когда кто-либо пишет туда, блокировки препятствуют прочим как читать, так и писать.

Можно было бы надеяться, что верно следующее утверждение:

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

К сожалению, при работе с CVS это утверждение неверно. Например, если имеются файлы

a/one.c
a/two.c
b/three.c
b/four.c

и кто-то выполняет

cvs ci a/two.c b/three.c

а затем кто-то еще в то же самое время выполняет cvs update, то он может получить изменения для `b/three.c', и не получить изменения в `a/two.c'.

Как отследить, кто редактирует файлы?

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

Для получения максимального преимущества разработчики должны использовать cvs edit (а не chmod), чтобы сделать файлы доступными для чтения/записи, и cvs release (а не rm) для удаления рабочего каталога, который более не используется. CVS не может вынудить их делать так.

Как с помощью CVS следить за определенными файлами?

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

Команда: cvs watch on [-lR] файлы ...

Команда означает, что разработчикам нужно выполнить команду cvs edit перед редактированием файлов. Для того, чтобы напомнить об этом разработчикам, CVS создаст рабочие копии файлов в режиме только для чтения.

Если среди файлов есть имя каталога, CVS включает слежение за всем файлами, находящимися в соответствующем каталоге репозитория и автоматически включает режим слежения за всеми файлами, которые будут в дальнейшем добавлены в каталог; это позволяет пользователю задать стратегию уведомлений для каждого каталога. Содержимое каталога обрабатывается рекурсивно, если только не задан ключ командной строки -l. Ключ -R позволяет включить рекурсивное поведение, если в файле `~/.cvsrc' оно было выключено с помощью ключа -l (see section Ключи по умолчанию и файл ~/.cvsrc).

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

Команда: cvs watch off [-lR] файлы ...

Команда означает, что при извлечении не нужно создавать файлы в режиме только для чтения; таким образом, разработчики не будут получать напоминания о необходимости использования cvs edit и cvs unedit. CVS будет извлекать файлы в обычном режиме, если только на файле не установлены специальные права доступа, разрешенные с помощью ключевого слова PreservePermissions в административном файле `config' (см. section Специальные файлы и See section Файл конфигурации CVSROOT/config).

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

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 edit. Некоторые системы называют это извлечение, но пользователи CVS уже используют этот термин в смысле "получение копии исходных текстов" (see section Получение исходного кода), а эту операцию, в свою очередь, другие системы называют взять.

Команда: cvs edit [ключи] файлы ...

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

Команда cvs edit принимает такие же ключи командной строки, что и команда cvs watch add, и устанавливает временное слежение за файлами для пользователя; CVS прекратит слежение, когда будет выполнена команда unedit или команда commit. Если пользователь не хочет получать уведомления, он должен указать ключ -a none.

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

Предупреждение: если в репозитории разрешена опция PreservePermissions (see section Файл конфигурации CVSROOT/config), то CVS не будет менять прав доступа к файлам. Причина этого изменения -- убедиться, что cvs edit не мешает хранению прав доступа к файлам в CVS-репозитории.

Обычно, когда вы закончите редактирование файлов, используйте команду cvs commit, которая проверит ваши изменения и вернет файлы, за которыми производилось слежение, в обычное состояние только для чтения. Если же вы вместо этого решите отменить изменения, или просто не станете ничего менять, используйте команду cvs unedit.

Command: cvs unedit [-lR] files ...

Отбросить все изменения в рабочих файлах files и привести их в соответствие с ревизией в репозитории. Если кто-либо запросил уведомление об изменениях каких-либо файлов, то CVS делает эти файлы доступными только для чтения. CVS уведомляет пользователей, которые запросили уведомление о команде unedit.

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

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

При использовании сетевого CVS вы можете использовать команды cvs edit и cvs unedit, даже если CVS не смогла успешно соединиться с сервером. Уведомления будут посланы при следующем успешном выполнении какой-либо команды CVS.

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

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

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

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

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

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

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

Использование слежений со старыми версиями 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 не пытается насильно внедрить какой-либо способ. CVS -- это просто инструмент, который можно использовать различными способами.

Блокированные извлечения могут оказывать отрицательное влияние на производительность. Если два человека хотят отредактировать различные части файла, какие могут быть причины помешать кому-нибудь из них сделать это? Обычным делом также является заблокировать файл, предполагая поредактировать его, а затем забыть снять блокировку.

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

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

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

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

Управление ревизиями

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

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

Когда фиксировать изменения?

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

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

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

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

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

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

Список ключевых слов

Вот список ключевых слов:

$Author$

Имя пользователя, который поместил ревизию в репозиторий.

$Date$

Дата и время (в UTC), когда была зафиксирована ревизия.

$Header$

Стандартный заголовок, содержащий полное имя RCS-файла, номер ревизии, дату в UTC, имя автора, состояние и имя блокировавшего этот файл (если файл заблокирован). Файлы обычно не блокируются при использовании CVS.

$Id$

Точно так же, как $Header$, только имя RCS-файла указано без полного пути.

$Name$

Имя метки, использованной при извлечении этого файла. Это ключевое слово заменяется только если при извлечении было явно задано имя метки. Например, при выполнении команды cvs co -r first это ключевое слово заменяется на `Name: first'.

$Locker$

Имя пользователя, который заблокировал эту ревизию (пустое, если файл не заблокирован, как обычно и бывает, если не использовалась команда cvs admin -l).

$Log$

Журнальное сообщение, которое было введено во время фиксации изменений, перед которым идет имя RCS-файла, номер ревизии, имя автора и дата в UTC. Существующие журнальные сообшения не заменяются. Вместо этого, новое журнальное сообщение добавляется после $Log:...$. Каждая новая строка содержит в начале ту же самую строку, которая находится перед ключевым словом $Log$. Например, если в файле находится

 /* Here is what people have been up to:
 *
 * $Log: frob.c,v $
 * Revision 1.1 1997/01/03 14:23:51 joe
 * Add the superfrobnicate option
 *
 */

то перед дополнительными строками, которые добавляются при замене ключевого слова $Log$, будет находиться ` * '. В отличие от предыдущих версий CVS и RCS, префикс комментария из RCS-файла не используется. Ключевое слово $Log полезно при накоплении полного журнала изменений в исходном файле, но по нескольким причинам это может привести к определенным проблемам. See section Проблемы с ключевым словом $Log$..

$RCSfile$

Имя RCS-файла без полного пути.

$Revision$

Номер ревизии.

$Source$

Полное имя RCS-файла.

$State$

Состояние, присвоенное ревизии. Состояния могут назначаться с помощью cvs admin -s -- см. section Ключи команды admin.

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

Для того, чтобы поместить в файл ключевое слово, вы просто пишете в нём, например, $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 $";

Как избежать подстановки

Подстановка ключевых слов имеет свои недостатки. Иногда бывает нужно, чтобы строка `$'Author$ появилась в файле без того, чтобы CVS интерпретировала её как ключевое слово и заменила на что-нибудь типа `$'Author: ceder $.

К сожалению, нельзя выборочно отключить подстановку ключевых слов. Можно использовать ключ командной строки `-ko' (see section Режимы подстановки), чтобы полностью выключить подстановку.

Во многих случаях вам нужно избежать использования ключевых слов в исходном тексте, даже несмотря на то, что они появятся в конечном продукте. Например, исходный текст этого руководства содержит `$@asis{}Author$' везде, где должна появиться строка `$'Author$. При использовании nroff и troff можно поместить в ключевое слово нулевой символ \&, чтобы добиться подобного эффекта.

Режимы подстановки

Вместе с каждым файлом хранится режим подстановки по умолчанию, и каждая копия файла в рабочем каталоге также имеет режим подстановки. Режим по умолчанию задается с помощью ключа `-k' команд cvs add и cvs admin; режим в рабочем каталоге задается с помощью ключей `-k' и `-A' команд cvs checkout и cvs update. Команда cvs diff также имеет ключ `-k'. Некоторые примеры приведены в section Обработка двоичных файлов.

Доступные режимы таковы:

`-kkv'

Генерировать строки из ключевых слов стандартным образом, то есть из ключевого слова Revision получается $Revision: 5.7 $.

`-kkvl'

Подобно `-kkv', только всегда указывается имя блокировщика, если данная ревизия в настоящий момент заблокирована. Имя блокировщика имеет смысл только если используется cvs admin -l.

`-kk'

Генерировать только имена ключевых слов и опускать их значения. Например, для ключевого слова Revision получается строка $Revision$, а не $Revision: 5.7 $. Этот ключ полезен для игнорирования изменения, возникших в результате подстановки ключевых слов, при сравнении разных ревизий файла.

`-ko'

Генерирует старую строку, присутствовавшую в рабочем файле перед тем, как он был зафиксирован. Например, для ключевого слова Revision генерируется строка $Revision: 1.1 $ вместо $Revision: 5.7 $, если она была записана именно так, когда файл был помещен в репозиторий.

`-kb'

Подобно `-ko', но также предотвращает преобразование символов конца строк между канонической формой, в которой они хранятся в репозитории (только символ перевода строки), и формой, принятой в используемой операционной системе. Для систем, подобных UNIX, в которых для завершения строк используется символ перевод строки, этот режим совпадает с `-ko'. Дальнейшая информация о двоичных файлах находится в section Обработка двоичных файлов.

`-kv'

Генерирует только значения ключевых строк. Например, для ключевого слова Revision генерируется строка 5.7 вместо $Revision: 5.7 $. Это может помочь при генерации файлов в языках программирования, в которых сложно отщепить разделители, такие как $Revision: $, от конца строки. Однако, дальнейшая подстановка ключевых слов не может быть осуществлена, когда удалены ключевые слова, поэтому этот ключ нужно использовать осторожно. Часто бывает полезно использовать `-kv' совместно с командой cvs export -- see section Команда export: экспортировать исходные тексты. Помните только, что этот ключ некорректно экспортирует двоичные файлы.

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

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

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

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

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

Слежение за чужими исходными текстами

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

В терминологии, используемой в CVS, поставщик программы называется производителем. Неизмененный комплект поставки помещается на отдельную ветку, которая называется ветка производителя. CVS резервирует для этой цели ветку с номером 1.1.1.

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

Используйте команду import для создания и обновления ветки производителя. Когда вы импортируете новый файл, ветка производителя становится "головной" ревизией (HEAD), поэтому все, кто извлекает копию файла, получают эту ревизию. Когда локальные модификации фиксируются, они помещаются в основной ствол и становятся "головной" (HEAD) ревизией.

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

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

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

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

$ cd wdiff-0.04
$ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04

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

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

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

$ tar xfz wdiff-0.05.tar.gz
$ cd wdiff-0.05
$ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05

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

$ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff

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

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

$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff

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

Возврат к последней версии от поставщика

Вы также можете полностью отменить локальные изменения и вернуться к последней версии от поставщика, установив головную ревизию в ветку поставщика для всех файлов. Например, если у вас есть извлеченная копия исходников в `~/work.d/wdiff', и вы хотите вернуть все файлы в этом каталоге в то состояние, в котором вам предоставил их поставщик, напечатайте:

$ cd ~/work.d/wdiff
$ cvs admin -bWDIFF .

Вы должны написать `-bWDIFF' без пробелов после `-b'. See section Ключи команды admin.

Как обрабатывать двоичные файлы при импорте в CVS

Используйте опцию `-k', чтобы сказать команде `import', что файлы являются двоичными. See section Файл `cvswrappers'.

Как обрабатывать замену ключевых слов при импорте в CVS

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

Чтобы сохранить содержимое ключевых слов, добавьте к команде cvs import при первом импорте ключ `-ko'. Это полностью выключит замену ключевых слов для этого файла, поэтому если хотите, то можете выборочно использовать разные ключи `-k' с командами cvs update и cvs admin.

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

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

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

Например, предположим, что есть две команды: красная и синяя, и обе посылают вам исходные тексты. Вы хотите импортировать результаты работы красной команды в ветку 1.1.1 и использовать метку поставщика `RED'. Вы также хотите импортировать работу синей команды на ветку 1.1.3 и использовать метку поставщика `BLUE'. Вы можете использовать такие команды:

$ cvs import dir RED RED_1-0
$ cvs import -b 1.1.3 dir BLUE BLUE_1-5

Заметьте, что если метка поставщика не соответствует ключу `-b', то CVS не обнаружит этот случай! Например,

$ cvs import -b 1.1.3 dir RED RED_1-0

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

Как ваша система сборки взаимодействует с CVS

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

Обычным вопросом, особенно для людей, знакомых с RCS, является "как сделать так, чтобы проект компилировался из самых свежих исходных текстов. Ответ на этот вопрос неоднозначен. Во-первых, так как CVS может рекурсивно обходить дерево каталогов, то не требуется изменять ваши файлы `Makefile' (или тот файл, что используется вашими инструментами для сборки), чтобы убедиться, что каждый файл является самым свежим. Вместо этого просто используйте две команды, сначала cvs -q update, а затем make или ту команду, которую вы выполняете, чтобы запустить вашу систему сборки. Во-вторых, вам не обязательно требуется получать копии изменений, которые сделал кто-то другой, пока вы не закончили свою собственную работу. Рекомендуется сначала обновить ваши исходные тексты, затем сделать изменение, собрать проект, проверить его, а затем зафиксировать изменения (сначала опять обновив исходники, если требуется). Периодически (в промежутке между изменениями, используя описанный подход) обновляя всё дерево исходных текстов, вы остаётесь в уверенности, что ваши исходники достаточно свежи.

Обычно необходимо записывать, какие ревизии исходных файлов использовались для построения конкретной версии продукта. Такая функциональность иногда называется списком использованных материалов. Лучшим способом добиться этого с помощью CVS --- использовать команду tag (see section Метки ревизий).

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

Другой подход -- создать структуру, позволяющую разработчикам иметь собственные копии некоторых файлов, а за остальными файлами обращаться в центральное хранилище. Многие предлагали подобные системы, используя такие возможности, как символические ссылки, существующие во многих операционных системых, или механизм VPATH, поддерживаемый многими версиями программы make. Например, одним из инструментов для сборки проекта, разработанным для этого, является Odin (см. ftp://ftp.cs.colorado.edu/pub/distribs/odin).

Специальные файлы

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

Если в репозитории установлена переменная PreservePermissions (see section Файл конфигурации CVSROOT/config), то CVS сохранит в репозитории такие характеристики файлов:

• пользователь- и группа-владелец файла
• права доступа
• основной и вспомогательный номер устройства
• символические ссылки
• структуру жестких ссылок

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

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

Более тонким различием является то, что CVS считает, что файл изменился, только если изменилось его содержимое (особенно если время модификации рабочего файла не совпадает с временем модификации файла в репозитории). Таким образом, если у файла изменились только права доступа, владелец, или основной и вспомогательный номера устройства, то CVS не заметит этого. Для того, чтобы принудительно поместить такое изменение в репозиторий, используйте ключ `-f' команды `cvs commit'. Это также означает, что если права доступа файла изменились, а файл в репозитории новее, чем рабочая копия, то выполнение `cvs update' просто изменит права доступа на рабочей копии.

Изменение жестких ссылок в репозитории CVS является особенно тонкой процедурой. Предположим, что файл `foo' был связан с файлом `old', а затем связан с файлом `new'. Вы можете попасть в необычную ситуацию, когда несмотря на то, что у `foo', `old' и `new' изменилось количество жестких ссылок, только файлы `foo' и `new' были изменены, поэтому `old' не является кандидатом на фиксирование в репозитории. Таким образом можно прийти к результатам, несоответствующим действительности. Если необходимо хранить в репозитории жесткие ссылки, мы рекомендуем применять команду touch ко всем файлам, чьи ссылки или статус изменились со времени последней фиксации. В действительности, было бы правильным выполнять touch * перед каждой фиксацией, если в каталоге находится сложная система ссылок на файлы.

Стоит заметить, что только обычные файлы могут быть объединены, по причинам, которые, надеемся, очевидны. Если `cvs update' или `cvs checkout -j' попытаются объединить символическую ссылку с обычным файлом, или два файла устройств друг с другом, то CVS сообщит о конфликте и откажется производить объединение. В то же самое время `cvs diff' не сообщит о различиях между этими файлами, потому что с файлами, не содержащими текста, нельзя совершать текстуальные сравнения.

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

Руководство по командам CVS

В этом приложении описывается общая структура команд CVS, а некоторые команды описываются детально; краткий справочник по командам CVS находится в see section Краткий справочник по командам CVS.

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

Общий формат всех команд CVS таков:

cvs [ опции_cvs ] команда_cvs [ опции_команды ] [ аргументы_команды ]

cvs

Имя исполняемого файла CVS.

cvs_options

Некоторые ключи командной строки влияют на все подкоманды CVS. Такие ключи описаны ниже.

cvs_command

Одна из нескольких подкоманд. Некоторые команды имеют синонимы, которые указываются в справочнике по этой команде. Есть только две ситуации, в которых вы можете пропустить `команду_cvs': `cvs -H' выдает список доступных команд, а `cvs -v' отображает версию CVS.

command_options

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

command_args

Аргументы команд.

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

Код выхода CVS

CVS может сообщить вызывающей программе, успешно ли завершилась операция или нет, возвращая тот или иной код выхода. Точный способ проверки кода выхода зависит от операционной системы. Например, в скриптах оболочки UNIX переменная `$?' содержит ноль, если последняя команда возвратила код успешного выхода, или же больше нуля, если выполнение программы завершилось с ошибкой.

Если CVS выполняется успешно, то возвращает код успешного завершения; в случае ошибки программа печатает сообщение об ошибке и возвращает код неуспешного завершения. Исключением является команда cvs diff. Она возвращает код успешного завершения, если не обнаружила различий, или же код неудачного завершения, если были обнаружены различия или произошла ошибка. Так как такое поведение не обеспечивает простого способа обнаружения ошибок, в будущем, вероятно, команда cvs diff будет изменена, чтобы вести себя подобно прочим командам CVS.

Ключи по умолчанию и файл ~/.cvsrc

Имеются определённые ключи команд CVS, которые используются столь часто, что вы захотите настроить для них что-то типа синонима. Основным примером (именно он и привел к поддержке файла `~/.cvsrc') является то, что многим не нравится стандартная форма выдачи изменений, которая используется в команде `diff', и они предпочитают контекстную или унифицированную выдачу изменений, которые выглядят значительно лучше.

Файл `~/.cvsrc' -- это способ установить ключи по умолчанию для команд CVS, не используя синонимов, скриптов оболочки и т. п.

Формат файла `~/.cvsrc' прост. В нем ищется строка, чье начало совпадает с именем выполняемой команды CVS. Если совпадающая строка найдена, то остаток строки расщепляется на ключи командной строки и добавляется к командной строке перед ключами из настоящей командной строки.

Если у команды есть два имени (например, checkout и co), то для поиска используется официальное имя, не обязательно совпадающее с тем, что использовалось при вызове CVS. Таким образом, если содержимое файла `~/.cvsrc' таково:

log -N
diff -u
update -P
checkout -P

то к аргументам команды `cvs checkout foo' добавится ключ `-P', и точно то же самое произойдет с командой `cvs co foo'.

При использовании вышеприведенного файла команда `cvs diff foobar' будет выдавать изменения в унифицированном формате. `cvs diff -c foobar' будет, как обычно, выдавать контекстные изменения. Получение изменений в "старом" формате чуть более сложно, потому что у команды diff нет способа задать выдачу в "старом" формате, поэтому вам потребуется использовать `cvs -f diff foobar'.

Вместо имени команды вы можете использовать cvs, чтобы задать глобальные ключи (see section Глобальные ключи командной строки). Например, такая строка в файле `~/.cvsrc' включит использование шестого уровня компрессии:

cvs -z6

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

Вот список имеющихся ключей командной строки 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.

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

В этой главе описываются `ключи_команды', доступные для использования с несколькими командами CVS. Эти ключи всегда задаются справа от имени `команды_CVS'. Не все команды поддерживают эти ключи, но лишь те, для которых ключ имеет смысл. Однако, если команда имеет один из этих ключей, вы можете быть уверены в одинаковом поведении этих ключей с разными командами. (Другие ключи команд, описанные вместе с отдельными командами, могут иметь различное поведение с разными командами CVS).

Предупреждение: команда `history' является исключением, она поддерживает различные ключи, конфликтующие даже со стандартными ключами.

@macro std-option-f

$ cvs checkout tc

$ cvs checkout -D yesterday tc

$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
$ cvs checkout -r FCS1_2_Patch product_module
$ cd product_module
[[ hack away ]]
$ cvs commit

[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs update -r EXPR1
$ cvs commit

[[ hacked sources are present ]]
$ cvs tag -b EXPR1
$ cvs commit -r EXPR1

$ cvs checkout -r EXPR1 whatever_module

-0 -1 -2 -3 -4 -5 -6 -7 -8 -9
--binary
--brief
--changed-group-format=arg
-c
 -C nlines
 --context[=lines]
-e --ed
-t --expand-tabs
-f --forward-ed
--horizon-lines=arg
--ifdef=arg
-w --ignore-all-space
-B --ignore-blank-lines
-i --ignore-case
-I regexp
 --ignore-matching-lines=regexp
-h
-b --ignore-space-change
-T --initial-tab
-L label
 --label=label
--left-column
-d --minimal
-N --new-file
--new-line-format=arg
--old-line-format=arg
--paginate
-n --rcs
-s --report-identical-files
-p
--show-c-function
-y --side-by-side
-F regexp
--show-function-line=regexp
-H --speed-large-files
--suppress-common-lines
-a --text
--unchanged-group-format=arg
-u
 -U nlines
 --unified[=lines]
-V arg
-W columns
 --width=columns

$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c

$ cvs diff -r RELEASE_1_0 -r EXPR1

$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs

$ cvs diff -u | less

$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
$$ Mail -s 'Исправления, которые Вы запрашивали' foo@example.net

$ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name
cvs rdiff: Diffing module-name
File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
File bar.h,v changed from revision 1.29.2.1 to 1.2

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

cvs [ global_options ] command [ command_options ] [ command_args ]

-kkv $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $
-kkvl $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
-kk $Id$
-kv file1,v 1.1 1993/12/09 03:21:13 joe Exp
-ko не подставлять
-kb не подставлять, файл является двоичным

$Author: joe $
$Date: 1993/12/09 03:21:13 $
$Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
$Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $
$Locker: harry $
$Name: snapshot_1_14 $
$RCSfile: file1,v $
$Revision: 1.1 $
$Source: /home/files/file1,v $
$State: Exp $
$Log: file1,v $
Revision 1.1 1993/12/09 03:30:17 joe
Initial revision

amodule -a first-dir

$ cvs co amodule
$ cvs co first-dir

cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile

regmodule first-dir

$ cvs co regmodule
cvs checkout: Updating regmodule
U regmodule/file1
U regmodule/file2
cvs checkout: Updating regmodule/sdir
U regmodule/sdir/sfile
$

regfiles first-dir/sdir sfile

$ cvs co regfiles
U regfiles/sfile
$

mname [ options ] &module...

ampermod &first-dir

$ cvs co ampermod

ampermod/first-dir/file1
ampermod/first-dir/file2
ampermod/first-dir/sdir/sfile

$ 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
$

exmodule -a !first-dir/sdir first-dir

маска_файла [ключ значение][ключ значение]...

cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag

BugId:

#!/bin/sh
#
# bugid.verify filename
#
# Verify that the log message contains a valid bugid
# on the first line.
#
if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
 exit 0
else
 echo "No BugId found." exit 1
fi

^tc /usr/cvssupport/bugid.edit

^tc /usr/cvssupport/tc.template

BugId:

#!/bin/sh
#
# bugid.edit filename
#
# Call $EDITOR on FILENAME, and verify that the
# resulting file contains a valid bugid on the first
# line.
if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
$CVSEDITOR $1
until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
do echo -n "No BugId found. Edit again? ([y]/n)" read ans
 case ${ans} in
 n*) exit 1;;
 esac
 $CVSEDITOR $1
done

^tc /usr/cvssupport/bugid.edit

^tc /usr/cvssupport/tc.template

/u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13

ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log
^prog1 Mail -s %s ceder

#!/bin/sh
(echo "------------------------------------------------------";
 echo -n $2" ";
 date;
 echo;
 cat) >> $1

^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs;
 cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

cvs -s TESTDIR=/work/local/tests

Roxanne Brunskill <rbrunski@datap.ca>,
Kathy Dyer <dyer@phoenix.ocf.llnl.gov>,
Karl Pingle <pingle@acuson.com>,
Thomas A Peterson <tap@src.honeywell.com>,
Inge Wallin <ingwa@signum.se>,
Dirk Koschuetzki <koschuet@fmi.uni-passau.de>
and Michael Brown <brown@wi.extrel.com>.