Система контроля версий ClearCase

Авторы: Юрий МИЩЕНКО
Кафедра КСУ, МГТУ "Станкин"
Дмитрий БАБАК
Кафедра КСУ, МГТУ "Станкин"

Введение

Система контроля версий ClearCase предназначена для помощи группам разработчиков в контроле над версиями объектов. Система ClearCase может быть использована совместно как с частными технологиями управления версиями, так и с UCM процессом (процессом унифицированного управления версиями, входящего в состав RUP - Rational Unified Process). Данная статья содержит вводную информацию по работе с системой ClearCase.

Базовая терминология ClearCase

Пользователи системы ClearCase делятся на следующие группы:

• администраторы;
• менеджеры проектов;
• интеграторы и разработчики.

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

Элементы и их версии

Система контроля версий работает с версиями элементов. В качестве элементов могут выступать файлы различного типа: исходный текст модуля, текстовый документ, исполняемая программа или база данных. У каждого элемента имеется набор версий. База данных VOB (см. ниже) хранит сведения обо всех версиях всех элементов.

Компонент

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

База версий объектов VOB (versioned object base)

База объектов (VOB) является основным хранилищем всех версий элементов одного компонента. Например, элемент (файл) foo.c может иметь 5 версий (0-4), элемент util.c - 2 версии, bas.c - 4 версии, bar.c - 5 версий (рис. 1).

Рис. 1. Элементы и их версии в ClearCase

Если вышеприведенные файлы принадлежат одному компоненту, то все они будут храниться в одной базе VOB. При работе в ClearCase часто возникает ситуация, когда один и тот же элемент должен иметь несколько параллельно развивающихся ветвей версий. ClearCase поддерживает механизм параллельного учета линеек версий. Процесс разделения дерева версий элемента называется branching. База VOB имеет владельца (owner), основную группу (primary group), список дочерних групп (group list) и режим защиты (protection mode). Все эти характеристики определяют права доступа к базе данных VOB. Права доступа могут быть изменены при необходимости, например, при перераспределении обязанностей в рабочей группе. Кроме обычных VOB существуют PVOB (Project versioned object base). База данных PVOB должна существовать для каждого проекта в системе. Объекты PVOB используются UCM для хранения внутренней информации, в частности, для хранения информации об активностях и потоках. Третий тип VOB - Administrative VOB используется для хранения глобальных определений элементов, атрибутов и гиперссылок.

Вид (View)

Локальная копия проекта, используемая разработчиком или интегратором для изменения файлов, называется видом. Вид создается для каждого пользователя системы ClearCase. Возможно создание разделяемых между пользователями видов. Вид реализуется в виде директории, содержащей копию файловой структуры проекта. Он предоставляет доступ к определенным компонентам, т.е. к набору элементов, соответствующих некоторой линейке версий. Кроме того, вид служит целью сформировать рабочее место разработчика, не давая доступа ко всей иерархии версий элементов и изолируя разработчика от других пользователей системы. Существуют два типа видов: динамический (Dynamic) и статический (Snapshot). Наиболее часто в работе используется статически вид. В отличие от него динамический вид позволяет иметь доступ к последним версиям файлов, непосредственно в базе VOB. В то время как в статическом виде для этого необходимо выполнить обновление вида (Update). Динамический вид реализуется в операционной системе Windows в виде подключенного удаленного диска. В ClearCaseLT возможность работы с динамическими видами не предусмотрена.

Активность (Activity)

Всякую модификацию элементов пользователь обязан делать в рамках той или иной "активности". Активность формально описывает причину той или иной модификации элементов в компоненте. Например, пользователю необходимо исправить ошибку с номером 222, а затем добавить поддержку протокола ААА в разрабатываемой системе. Тогда все модификации файлов, относящихся к исправлению ошибки, он должен делать в рамках одной активности (ее имя может быть, к примеру, "BugFix 222"), а добавление поддержки протокола ААА - в рамках другой активности ("Adding AAA protocol"). Активность описывается следующими атрибутами:

• название активности;
• автор;
• набор элементов и их версий, в которые были внесены изменения.

Базовая линейка версий (Baseline)

Версии элементов в компоненте объединяются в базовые линейки версий (Baseline). Базовая линейка версий определяет именованный набор согласованных версий элементов тем самым, определяя версию компонента. В процессе разработки базовая линейка версий может соответствовать, например, черновому варианту проекта, бета-версии, финальной версии. В процессе работы с проектом, менеджер или интегратор создают базовые линейки версии и изменяют доступ к ним разработчиков. Например, на рис.2 показаны три базовые линейки версий b1, b2 и b3. Базовая линейка версий b1 состоит из версий файлов a0, b0, c0, d0 и e0. b2 состоит из версий файлов a1, b1, c1, d0, e1, а b3 - из версий a2, b2, c1, d2, e1. Таким образом, процесс развития компонента состоит в разработке новых базовых линеек, их отладке и включении в компонент.

Рис.2. Базовые линейки версий

Каждой базовой линейке может быть сопоставлен так называемый уровень обеспечения (Promotion Level). Особое значение имеет уровень "рекомендуемая базовая линейка версий". Операция обновления файлов из базы данных VOB (Rebasing) по умолчанию выбирает версии элементов, соответствующие базовой линейке.

Поток (Stream)

Поток - это набор данных, включающий в себя:

• активности пользователя;
• текущую базовую линейку версий;
• виды, с которыми пользователь ведет работу;
• локальные копии компонентов.

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

Ветвь (Branch)

Ветвь - это некоторый объект, хранящий информацию о последовательности версий элемента. Каждый элемент обязательно имеет главную ветвь (main branch), отражающую процесс развития элемента. Главная ветвь может иметь несколько подветвей (subbranches), каждая из которых будет относиться к отдельным путям развития элемента. На рис.3 показана основная ветвь main и две подветви r1_bugs и bug404.

Рис.3. Главная ветвь и подветви

Ветви всегда образуются, когда более одного разработчика работают с одним и тем же элементом. Для образования новой базовой линейки версии необходимо объединить (merge) различные подветви элемента. (см. рис 4).

Рис. 4. Объединение версий

Каждой версии элемента может быть сопоставлена одна или несколько меток (version label). Как правило, метки используются, чтобы выделить версии, относящиеся к важным для развития проекта событиям (рис. 5).

Рис. 5. Метки версий

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

Рис. 6. Устойчивая версия компонента

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

Проект (Project)

Под проектом в ClearCase понимается окружение системы контроля версии, используемое одной группой разработчиков. Обычно проект сопоставляется продукту, получаемому в процессе разработки. Им может быть: web-сайт, пакет прикладных программ и т.д. В окружение проекта входят компоненты, потоки интеграции и потоки разработчиков, активности и виды. Для каждого проекта необходимо указание PVOB базы данных. Обновление из базы данных (Rebasing) и доставка в базу данных (Delivering) Общий алгоритм работы с элементами системы ClearCase состоит из следующих этапов:

• обновление из базы данных (Rebasing);
• последовательность операций взятия элемента на изменение (check-out), модификации элемента и освобождения элемента (check-in);
• доставка изменений в базу данных (Delivering);
• создание новой базовой линейки версий проекта.

Процедура обновления из базы данных (Rebasing) необходима для выбора и копирования в локальный вид разработчика (Developer View) той или иной базовой версии компонентов. В качестве базовой линейки версий обычно используется "рекомендованная базовая линейка версий", назначаемая интегратором (администратором) проекта. При наличии в виде (view) файлов взятых на изменение (check-in) обновление из базы данных обычно запрещается. Для выбора версий элементов в процессе копирования из базы данных (Rebasing) используется специальная спецификация конфигурации (configuration specification). Она содержит правила, которые используются видом (view) для выбора необходимых версий элементов. Например, в спецификации может быть указано, что для данного вида необходимо брать последние версии элементов. Каждая операция взятия элемента на изменение (check-out) обычно сопровождается созданием дополнительной ветви элемента (branch) для разработчика, который работает с этим элементом. Изменение элемента разрешается только в интервале между операциями check-out и check-in. Именно в этом интервале ClearCase снимает с файла атрибут "только для чтения" (read only). Изменение элемента в любое другое время приводит к созданию так называемых hijacked файлов. Модификация этих файлов происходит вне стандартного алгоритма, предусмотренного ClearCase, поэтому появление их в процессе работы нежелательно, а процедура внесения их базу данных требует дополнительных операций. После работы над элементами необходимо сделать доставку изменений в базу данных (Delivering). В зависимости от установленной политики, разработчику может быть предложено предварительно произвести операцию обновления (Rebasing). При наличии измененных файлов в локальном виде разработчика эта операция сопровождается объединением версий файлов (merging). Обычно операция объединения выполняется системой автоматически. Однако в ряде случаев система прибегает к помощи разработчика. В других случаях пользователь выполняет операцию доставки изменений без операции объединения (merging). При этом за объединение различных ветвей элемента отвечает интегратор. Внесенные изменения в базу данных не могут быть доступны для других пользователей до выполнения операции создания базовой линейки версий (Baseline). Эта операция обычно выполняется интегратором или в ряде случаев может быть возложена на разработчиков.

Заключение

Система ClearCase является очень развитой системой контроля версий, вводящей целую систему понятий, зачастую новых, не существующих в других системах. Данная система предназначена в первую очередь для ведения средних и крупных проектов, которыми занимаются группы разработчиков, не менее чем 4-6 человек. Для малых или краткосрочных проектов или проектов, которые выполняются небольшой группой разработчиков, нецелесообразно применение столь мощной системы, т.к. в ней требуется выполнять много административных функций, не имеющих непосредственного отношения к выполняемому проекту. Однако для средних и крупных проектов данная система является лучшим решением, которое обеспечивает согласованность выполнения операций, контроль хода развития проекта и планирование стратегических целей его развития.

Литература

1. Introducing Rational ClearCase LT. November 2000. Rational Software Corporation.
2. Administering ClearCase LT Document. Rational Software Corporation. 2000.
3. Managing Software Projects With ClearCase. Rational Software Corporation. 2000