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