@dircategory Средства разработки * cvs-ru: (cvs-ru). Система Управления Параллельными Версиями

Управление версиями с помощью CVS для CVS 1.10.8 Per Cederqvist et al Перевод на русский язык -- Алексей Махоткин

Copyright (C) 1992, 1993 Signum Support AB
Copyright (C) 1999-2001 Alexey Mahotkin (translation into Russian)

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation.

Перевод того же самого уведомления на русский язык (перевод, в отличие от уведомления на английском языке, законной силы не имеет):

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

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

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

@macro cvsver{ver} CVS \ver\

Обзор

Эта глава предназначена для людей, никогда ранее не использовавших 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. Дополнительная информация о сборке проектов при использовании CVS находится в section Как ваша система сборки взаимодействует с 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

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