В условиях совместной работы над проектом с поддержкой CVS (система параллельных версий, Concurrent Versions System) нескольких участников, каждый из которых работает в собственной Рабочей среде, рано или поздно возникает необходимость обменяться результатами работы. Для этого служит хранилище CVS.
CVS использует модель ветвей для поддержки параллельных потоков разработки, которые, будучи изолированными друг от друга, тем не менее очень тесно связаны. Ветви служат для интеграции сделанной работы всем коллективом разработчиков. Ветвь - это своего рода рабочая область, в которой накапливаются изменения, вносимые разработчиками в проект. В этой модели каждый разработчик работает индивидуально над коллективным проектом, хранящимся на сервере CVS, вносит свой вклад в общую работу и имеет доступ к разработкам других участников по мере развития проекта. Основная разработка ведется в ветви хранилища с названием HEAD, часто именующейся головной или стволовой ветвью.
Все разработки участников становятся общедоступными после того, как участники вносят их в ветвь. Подобно этому, последние разработки они могут получить, обновив свои рабочие области из ветви. Поэтому ветвь постоянно развивается с каждой новой разработкой ее участников.
Ветвь отражает текущее состояние проекта. В любой момент разработчик может обновить свою рабочую область из ветви и быть в курсе самых последних изменений.
CVS обеспечивает две важные функции для совместной работы:
Хронология работы участников коллектива
Способ координации и интеграции этой работы
Хронология важна тем, что позволяет сравнить текущую работу с прежними версиями, вернуться к прошлым версиям при необходимости и т.д. Координация работы очень важна для того, чтобы в каждый момент времени проект имел четко обозначенное состояние, отражающее коллективный вклад разработчиков. Координация достигается за счет применения модели ветвей.
Оптимистическая модель работы подразумевает, что изменения, вносимые участниками в доступные им ресурсы, ничем не ограничены. Когда над одним и тем же ресурсам работают два разработчика, вносимые ими изменения в ветвь могут конфликтовать между собой. Такие конфликты требуется разрешать. Модель называется оптимистической, поскольку предполагается, что конфликты возникают редко.
Как правило ресурсы имеют явные или неявные зависимости от других ресурсов. Например, Web-страницы содержат ссылки на другие Web-страницы, исходный код включает в себя ссылки на сущности, описанные в других участках кода. Никакой ресурс не существует изолированно, сам по себе.
Когда изменения ресурсов вносятся в ветвь, могут быть затронуты и эти зависимости. Обеспечение целостности зависимостей важно, поскольку ветвь отражает текущее состояние проекта, и в любой момент разработчик может взять содержание ветви за основу для продолжения работы.
Поэтому в идеальном рабочем процессе следует сохранять целостность данных в ветви.
Ниже показаны этапы идеального рабочего процесса:
Начните с нуля. Перед началом работы обновите ресурсы рабочей среды из текущих данных ветви. Если нет никаких ресурсов, которые следовало бы сохранить, быстрее всего будет выбрать требуемые проекты какой-либо ветви (возможно, HEAD) и выполнить команду Изъять (или Заменить на > Данные хранилища, если локальный проект уже существует). При этом все локальные ресурсы будут обновлены данными из ветви.
Измените ресурсы. Работая в локальной Рабочей среде, создайте новые ресурсы, измените существующие, сохранив их локально.
Синхронизируйте изменения. Когда вы готовы внести сделанные изменения в ветвь, выполните синхронизацию с хранилищем.
Обновите данные. Проверьте все входящие изменения и добавьте их в Рабочую среду. Тем самым вы проверите наличие изменений, которые могли бы повлиять на целостность данных, которые должны быть внесены в ветвь. Разрешите конфликты. Проверьте все еще раз, запустите программы проверки целостности, например найдите потерянные ссылки, скомпилируйте код и пр.
Внесите изменения в ветвь. Убедившись в том, что последние изменения не нарушают целостности данных, внесите их в ветвь. Для перестраховки еще раз выполните предыдущий этап, чтобы проверить, нет ли новых входящих изменений.
Конечно, это было описание идеального рабочего процесса. Иногда можно не сомневаться в том, что входящие изменения не повлияют на вашу работу, и внести свои изменения в ветвь, не обновляя перед этим данные. Однако вообще говоря разработчикам следует придерживаться описанной выше схемы работы, чтобы случайно не нарушить целостность данных в ветви.
С дополнительной информацией по CVS можно ознакомиться на сайте http://www.cvshome.org.
Хранилища CVS
Ветви
Версии
Синхронизация с хранилищем CVS
Создание расположения хранилища CVS
Изъятие проекта из хранилища CVS
Замена ресурсов в Рабочей среде
Совместное использование нового проекта с помощью CVS
Синхронизация с хранилищем
Обновление
Разрешение конфликтов
Объединение с данными из ветви
Внесение изменений в хранилище
Связанные справочники
CVS