Etc.: CVS – Система Управления Параллельными Версиями

• Обзор
• Репозиторий
• Начинаем проект под CVS
• Ревизии
• Создание ветвей и слияние
• Рекурсивное поведение
• Добавление, удаление и переименование файлов и каталогов
• Просмотр истории
• Обработка двоичных файлов
• Несколько разработчиков
• Управление ревизиями
• Подстановка ключевых слов
• Слежение за чужими исходными текстами
• Как ваша система сборки взаимодействует с CVS
• Специальные файлы
• Руководство по командам CVS
• Краткий справочник по командам CVS
• Справочник по административным файлам
• Все переменные окружения, используемые в CVS
• Совместимость между версиями CVS
• Исправление ошибок
• Титры
• Что делать с ошибками в 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).

Далее >>>