Часть 1. Репозиторий

Введение

Начиная с данной статьи, мы с вами будем по шагам исследовать такой неординарный продукт, как ClearCase. Открытая недавно рубрика "Мастерская ClearCase" накладывает свой отпечаток на стилистику изложения материала, так как "мастерская" подразумевает пошаговое изучение программного продукта с нуля до приличного уровня…

К выпуску планируется несколько связанных между собой статей, в которых по шагам исследуются возможности программы по принципу "от простого к сложному". В трилогии планируется затронуть практические аспекты применения программы на реальных примерах. Далее я постараюсь привести примерный план планируемых к размещению статей, а всем заинтересованным в дальнейшем продолжении трилогии предлагается присылать мне вопросы и предложения, связанные с тематикой ClearCase. Анализируя Ваши письма, мне будет легче планировать тематику дальнейших статей, создавая материал, наиболее точно соответствующий всем веяниям в кругах разработчиков. ClearCase - в массы!

Читаемый материал (статья номер 3) предполагает быстрое введение в сам продукт и в предметную область контроля версий, далее планируется описать интерфейс и особенности продукта. В следующих статьях хочется осветить следующие вопросы: Web-интерфейс, бренчи, слияние версий, формат репозиториев, формат видов, синхронизация реплик VOB при помощи MultiSite, команды ClearCase и MultiSite, механизмы интеграции со средствами разработки на примере Visual C++, механизмы лицензирования продукта.

Общие подробности программы

ClearCase - инструментальное средство, позволяющее управлять процессом создания программного продукта. Управление осуществляется посредством контроля версий всех входящих в состав проекта файлов, предоставляя администраторам, разработчикам и менеджерам получать полную информацию о текущем состоянии проекта. Проще говоря, программа создает специальную базу данных (VOB), в которой хранит всю сопроводительную информацию обо всех файлах с их версиями, которые были поставлены под контроль, в сопроводительной информации также указывается, кто и когда внес изменения в конкретную версию проектного файла или директории. Вся история изменений отображается в графическом виде, в форме дерева версий.

ClearCase позволяет решить многие проблемы, сопровождающие проект, в котором участвует более одного человека. Например, такая проблема, как синхронизация версий одного исходного файла, над которым трудились два-три (и более) программиста, в обычной жизни сведется к простому механическому труду объединения трех подверсий файлов в один, с неизбежной в таком случае потерей времени, которого всегда не хватает. Вторым примером может служить ситуация, когда разработчики вынуждены брать определенный объем работ на дом или в командировку, проводя соответствующие изменения в отрыве от офиса. Здесь проблема возникнет, когда разработчик придет в офис и попытается вставить в проект свою часть работы. При этом у него также возникнут проблемы с объединением, слиянием нескольких файлов для создания новой версии.

Я затронул только две наиболее типичные проблемы, которые объединяют все софтверные фирмы и на решения которых уходит драгоценное проектное время. Все проблемы перестают быть проблемами, как только ваша компания внедряет у себя программу ClearCase, чьей прямой обязанностью является прозрачное решение всех описанных проблем.

ClearCase одним из первых продуктов SCM (Source Code Management) включил в себя не только возможности контроля версий, но и управление рабочим пространством при помощи инвариантного подхода, пользуясь которым, разработчики смогут разрабатывать качественные программные продукты в короткие сроки, поддерживать уже созданные продукты, не путаясь в их версиях. Основное же отличие от конкурентов состоит не только в том, что у ClearCase более глобальный подход к решению задачи контроля версий, но и в том, что данная программа при помощи специальной утилиты "oMake" позволяет собирать проект в исполняемый файл. Подобную возможность не предоставляет ни один из конкурирующих пакетов.

Основные особенности ClearCase:

• Тотальное контролирование текущего состояния проекта
• Автоматические компрессия и кэширование проектных файлов/LI>
• Неограниченная передача управления
• Синхронизация географически удаленных групп разработчиков
• Создание разветвленного дерева версий
• Интегрирование с Visual Studio, PowerBuilder, Oracle Developer, FrontPage, MS Word
• Автоматическая сборка проекта
• Преобразование PVCS, SourceSafe, RCS и SCCS файлов

ClearCase тесно интегрируется со всеми инструментальными средствами компании Rational, некоторые из которых дополняют его функциональность. Например, Rational SoDA позволяет менеджерам и администраторам документировать, описывать текущее состояние проекта, основываясь на той информации, которая предоставляет SoDA.

Как видно из материала, ClearCase представляет собой серьезный и достойный продукт, помогающий выпускать софтверным компаниям более качественные программные продукты в реальные сроки. Тесная интеграция с наиболее популярными средами разработки приложений делает возможным получать доступ к проектной информации, пользуясь привычными инструментами.

ClearCase поддерживает многие платформы, но вся дальнейшая информация в статье будет касаться только его реализации под Windows.
Для данной платформы Rational выпускает продукт в двух вариантах:

• ClearCase
• ClearCase Attache

Первый, представлен двумя частями (клиентской и серверной), каждая из них является полнофункциональной, с разницей в особенностях администрирования и лицензирования.

Второй вариант - это усеченная версия продукта в которой не реализованы все функции полного продукта. Единственным плюсом Attache является его способность запускаться на платформах: Win3.0, Win3.1, Win95/98/NT.

Создание VOB

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

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

Если вкратце описать принцип работы пользователя в программе ClearCase, то получается следующий алгоритм:

1. Создается VOB (один или несколько)
2. Создается VIEW (один или несколько)
3. Необходимые проектные файлы ставятся под контроль в одном из VIEW
4. Сборка проекта

Словесное описание пунктов можно выразить так: создается одна или несколько баз данных (VOB), на их основе строятся виды (VIEWs), с которыми и работают все пользователи, создавая нужное количество. Любая операция постановки файлов под контроль сводится к копированию нужного файла на виртуальный диск, создаваемый VIEW. Далее к файлу применяются стандартные операции версионного контроля: "check in" и "check out", позволяющие включать или выключать контроль над файлами. Любой пользователь в любой момент может создать ответвление (branch) для самостоятельной правки, по окончании которой ClearCase объединит полученную версию с проектной (закроет ветвь). Итогом всей работы является сборка проекта про помощи "oMake".

Соответственно, основой любого проекта, или даже самим проектом, является VOB - Version Object Base - защищенный, масштабируемый репозиторий, хранящий в себе всю историю всех компонентов проекта. VOB - основа, фундамент любого проекта.

VOB представляет собой набор файлов и директорий, которые физически хранятся на выделенном компьютере. Репозиторий создается только в открытых (shared) каталогах. Собственный физический формат VOB не документирован. Все операции над файлами и каталогами делаются только через виртуальную файловую систему MVFS.

Спецификой ClearCase можно считать его UNIX корни, что выражается в особенных нотациях при вводе команд, нетипичных для пользователей Windows систем. Например, любой созданный можно отключить командой MOUNT и отключить командой UNMOUNT, что не очень типично для Windows.

Любая операция в ClearCase выполняется двумя способами: либо через графическую оболочку либо через командную строку. В зависимости от ситуации и степени подготовленности пользователя можно применять данные способы, как по раздельности, так и по очереди.

Создание VOB из оболочки

После запуска Clear Case Home Base на экране появляется окно, в котором находятся все рычаги управления программой. Нас интересует VOBs.

Как видно из представленного рисунка - графическая часть программы имеет достаточно дружественный интерфейс. Из четырех представленных операций нас интересует Create VOB.

Специфика создания репозиториев из графической оболочки сводится к тому, что программа автоматически его создает и регистрирует. Такой подход позволяет сокращать необходимое на создание базы время. В следующем шаге VOBу присваивается имя и комментарий (в дальнейшем комментарии будут достаточно часто использоваться в практических целях, поэтому нелишне выработать рефлекс их ввода).

На следующем витке программе необходимо указать место создания репозитория в формате:

\\имя_хоста\директория\имя_VOB.vbs

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

На последнем шаге можно задать имя мастер VOBа (административного) из числа смонтированных. Если было задан такой VOB, то создаваемый будет находиться в полном подчинении ему (станет дочерним VOB (subvob)). Пункт Reconnect the VOB at logon time заставит ClearCase автоматически монтировать VOB при входе в систему (по умолчанию флажок является выбранным).

Результатом всех вышеописанных действий будет создание VOB. Вход в него станет доступен на уровне виртуальной файловой системы MVFS только после создания специального VIEW, ориентированного на данный VOB.

Рассмотрим процесс создания VOB из командной строки.

Для работы на командном уровне необходимо воспользоваться инструментом cleartool, представляющем собой интерпретатор командной строки. Утилита запускается из пункта Start->Programs->ClearCase->ClearTool, либо из командной строки командой "cleartool". В результате на экран выведется окно с приглашением "cleartool>". Теперь возможен ввод команд ClearCase.

Version Object Base создает команда "mkvob" (make vob). Синтаксис выглядит следующим образом:

Mkvob [-c comment] [-tag vob_tag] [\\path]

Это простейший формат данной команды, в котором рассматриваются следующие настройки:

-с - задает комментарий для VOB

-tag - задает имя VOB

\\path - полный путь к создаваемому VOB

Рассмотрим, в качестве примера, следующую команду:

mkvob -c "alex" -tag \alloiz \\Novichkov\1\alloiz.vbs

Описание выглядит следующим образом: создать VOB с именем "alloiz", присвоить комментарий "alex". Хранить репозиторий надлежит в "alloiz.vbs" по указанному адресу к открытому каталогу "1".

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

Created versioned object base. Host-local path: Novichkov:C:\1\alloiz.vbs Global path: \\Novichkov\1\alloiz.vbs VOB ownership: owner NOVICHKOV\Administrator group NOVICHKOV\None VOBs have special data backup considerations. For more information on how to back up your VOB properly, see the documentation for administering ClearCase. If the backups aren't done properly, you are putting your data at risk! cleartool>

Теперь необходимо смонтировать VOB командой "mount \alloiz", что приведет к монтированию файловой системы MVFS для VOB "\alloiz" (при безошибочном исполнении команды, выведется следующая информация: "Mounting MVFS filesystem \alloiz")

Список всех имеющихся VOBов всегда можно узнать при помощи команды "lsvob".

Основные особенности VOB:

• Можно создавать в командной строке и из графической оболочки
• VOBы можно подключать и отключать (mount, unmount)
• VOBу при создании можно указать имя административного VOB
• Для большого проекта можно создать несколько VOB с одним административным, либо без такового

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

Часть 2. Построение видов

VIEWs, изучение основных свойств фильтров просмотра.

Второе опорное понятие в ClearCase, без которого невозможна работа в принципе - это View - система видов (представления информации), которая позволяет фильтровать все обращения к VOB, выводя только ту часть из них, которая была определена пользователем. Как уже упоминалось ранее ClearCase, осуществляет контроль над файлами при помощи стандартных операций "check in" и "check out", которые призваны вносить файл в рамки контроля, либо выводить его.

View позволяет получать доступ к файлам и данным проекта при помощи стандартных средств работы. Ими могут быть: "проводник", "Word", а также программы, проводящие любые файловые операции. Необходимость использования "видов" очевидна, так как без наглядного представления, данные не могут быть информативными. Если вновь вернуться к понятию фильтра, и посмотреть на View с этой точки зрения, то получается очень интересная картина: ведется проект, в котором скопилось по 10-20 версий каждого файла, и все из них, как положено, находятся в VOB, а работать команде необходимо только со свежей (последней) версией, то налицо проявляется основное (фильтрационное) свойство видов - они позволяют скрыть от глаз конечного пользователя всю кухню (историю создания), выводя на экран только последний релиз и все к нему относящееся.

ClearCase имеет возможность работы с двумя типами View, имеющими свою специфику в использовании: Dynamic View и Snapshot View.

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

Рассмотрим особенности обоих типов представления:

• Dynamic View
  Наиболее продвинутый тип. Позволяет с легкостью контролировать состояние всего проекта, поскольку в него попадают все репозитории, смонтированные на данный момент в системе. В техническом плане данные тип вида представляет собой виртуальную файловую систему, которой присваивается буква диска. Особенностью данной системы является возможность непосредственного просмотра всех файлов проекта. Вид подключается к серверу, на котором хранится репозиторий и передает всю информацию о состоянии всех файлов. Обновление информации при этом происходит незаметно (прозрачно) для пользователя. К сожалению, динамический способ просмотра доступен только из систем Windows NT и Unix.
• Snapshot View
  Также предоставляет информацию о состоянии фалов проекта. Отличие его состоит в том, что при его создании пользователь сам указывает репозитории и файлы, которые он хочет держать под контролем, после чего система ClearCase будет физически дублировать их с сервера на локальную станцию, при этом буква отдельная буква для вида не создается (вся информация размещается локально на указанном носителе). Любое обновление состояния файлов производится вручную, с периодичностью необходимой пользователю.

Как видно из вышеcказанного, оба вида имеют достоинства и недостатки, а посему придется использовать их совместно в зависимости от текущих потребностей. Например, если локальная сеть в организации построена на базе систем Windows NT и 98, то всем разработчикам в W98 придется работать только со Snapshot View. В случае же надомной работы или частых разъездов участников проекта, Snapshot View становятся просто незаменимы, ведь только данный тип представления позволяет получить "слепок" необходимых файлов, скажем, на переносной компьютер и уехать в командировку. По возвращении в офис разработчику останется только подключиться к сети и произвести обновление подконтрольных данных. Динамический способ просмотра, гарантирует Вам наиболее полный охват компонентов проекта, поскольку данный тип вида работает со всеми присоединенными репозиториями. Использование такого метода оправдано для менеджеров проекта, которым, в силу многих причин, необходимо иметь доступ ко всему проекту целиком.

Для работы с видами существуют такие стандартные для объектов операции как: создание, удаление, включение, отключение и обновление. Работа с видами тесно связана с таким мощным инструментом, как ClearCase Details, в чьи обязанности входит постановка/выведение файлов под контроль, получение справочной информации о конкретном элементе, вывод дерева версий… То есть, исходя из названия, данный модуль отвечает за все детали, относящиеся к контролю данных. Соответственно, разработчик большую часть времени будет проводить в работе с ClearCase Details.

На рисунке 3 отражено состояние окна ClearCase Home Base, в котором активна вкладка Views. Здесь отображено 5 операций над видами:

• Start View. Запускает отключенный вид. Рекомендуется использовать в тех случаях, когда при создании вида (динамического) не была установлена опция авто подключения при загрузке
• Edit View Properties. Изменяет свойства вида. Наравне с изменением свойств, здесь можно отключить на время работу вида.
• Create View. Создает вид (см. ниже)
• Remove View. Удаляет вид
• Update Snapshot View. Обновляет вид (только для Snapshot)

Оболочка

Начнем с создания Dynamic View.

Активизация Create View приводит к появлению вопроса о том будем ли мы создавать вид, базирующийся на проектном дереве (об этом чуть позже). Пропускаем данный шаг без изменения. На следующей вкладке выбирается тип создаваемого вида (рис.4). Выбираем Dynamic View.

Следующий шаг полагает введение информации об имени создаваемого вида, сопровождающем комментарии, букве диска, на котором будет смонтирована файловая система MVFS. Для задания пути к месторасположению вида на локальной машине необходимо войти в пункт Advanced, где в соответствии с правилами необходимо ввести полный путь к открытому каталогу (см. создание VOB). В соответствии с рекомендацией Rational, касающейся сохранения документов, можно предложить сохранять данные обо всем проекте в одном каталоге не "размазывая" по всему диску. По окончании ввода необходимой информации и нажатия на Finish можно воспользоваться итоговым окном, где можно еще раз проверить правильность задаваемых параметров (на рисунке 5 показано окно, в котором, в качестве имени View указано "Administrator_view2", а в качестве имени диска - "Y").

После нажатия "ОК" системой будет выведено сообщение либо об успешном создании указанного вида, либо список ошибок - в случае неудачи.

Результатом работы будет появление нового диска с меткой "Administrator_view2", куда, в качестве папок, будут внесены имена всех присоединенных (смонтированных) в данный момент VOB. Далее работа с динамическим видом будет продолжена в таком же ключе: как только создаетcя или присоединяется VOB - ссылка на него автоматически попадает во все активные динамические виды.

Snapshot View

С данным типом видов все также несложно. Первые шаг мы оставляем без изменений, пропуская ссылку на проектное дерево. Вторым шагом подтверждаем необходимость создания именно Snapshot View. Появившееся окно предполагает введение следующих данных: имя вида, место хранения (с указанием полного пути к директории), комментарий. По окончании всех предварительных манипуляций ClearCase представит окно со списком всех имеющихся в проекте VOB. Для полноценной работы можно выбрать либо весь VOB целиком, либо любой его компонент (начиная с конкретной директории и заканчивая отдельным файлом или группой выбранных файлов). На рисунке 6 отображено окно выбора, где и производятся все описанные манипуляции. При внимательном рассмотрении представленного списка можно и нужно рассмотреть следующие особенности:

• На рисунке представлено 4 VOB ("alloiz", "app_vob", "golder", "temp")
• В список загружаемых элементов внесена только директория SRC из APP_VOB со всеми файлами, входящими в нее.

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

Следует учесть особенность Snapshot: никакой виртуальной файловой системы для данного вида ClearCase строить не будет - все будет размещено локально.

Создание видов из командной строки

Как и при создании репозиториев, ClearCase позволяет создавать новые виды из командной строки (апплет cleartool). Для создания View существует команда "mkview", в чьи обязанности входит создание видов. Данная команда применяется как для создания Snapshot, так и для Dynamic видов. В зависимости от заданной спецификации будет создан необходимый тип вида со всеми переданными ему характеристиками. Создавать виды из командной строки сложнее чем репозитории, особенно это касается создания Snapshot View, в котором необходимо вручную править Config Spec (конфигурационную спецификацию).

Перед созданием вида рассмотрим семантику команды MKVIEW:

Для динамических видов:

mkview -tag view-tag [-tcomment tag-comment] [-tmode text-mode] 
	[-region network-region] [-cachesize size]
	[-shareable_dos / -nshareable_dos]
	[-host hostname -hpath host-stg-pname -gpath global-stg-pname]
	[-stream stream-selector]
	view-storage-pname 

Для снапшотов:

mkview -tag view-tag -snapshot [-vws view-storage-pname]
	[-tcomment tag-comment] [-tmode text-mode]
	[-cachesize size] [-ptime]
	[-host hostname -hpath host-stg-pname -gpath global-stg-pname]
	[-stream stream-selector]
	snapshot-view-pname 

Как и ранее, мы не будем останавливаться детально на каждом ключе в списке параметров вызова, а лишь изучим необходимые компоненты, для чего создадим динамический вид с именем "HELLO". Команда, выполняющая функцию, будет выглядеть следующим образом:

mkview -tag hello \\novichkov\1\hello 

Исполнение команды ведет к созданию динамического вида с именем "hello". Причем физически сам вид будет храниться на хосте с именем "novichkov", в открытой для доступа директории. Имя создаваемой директории, для хранения служебной информации, - "hello" (не путать с именем вида - наименования могут не совпадать). Независимо от способа создания View (визуально или из командной строки) ClearCase создает служебную директорию по указанному адресу, где хранит всю необходимую информацию в специальном представлении.

Продолжим создание видов на примере команды, вводящей в строй Snapshot View:

Mkview -tag hello -sna -vws \\novichkov\1\hello c:\snapa 

Результирующим действием введенной команды станет создание директории "snapa", в которую мы чуть позже добавим необходимые подконтрольные элементы. Ключ "vws" сообщает системе где будет храниться служебная информация о представлении данного вида. Переключатель "-sna" дает системе команду на создание именно Snapshot View. Первый параметр "-tag hello" задает имя вида.

При создании вида из командной строки необходимо провести ряд манипуляций, которые явно присутствуют при визуальном построении и напрочь отсутствуют в командной строке. Начнем рассмотрение особенностей с описания возникшей проблемы: вышеприведенная команда отлично справилась с задачей создания вида, но она создала только его каркас, описание, не включив подконтрольные элементы. Казалось бы система явно выполняет не совсем то, что хотелось…

На самом деле все обстоит гораздо сложнее и проще одновременно!

В системе есть целый набор свойств (properties), правил (rule) и спецификаций (Config Spec) по которым создается любой вид. Каждое из трех свойств можно изменять в процессе работы явно и неявно. Неявно происходят все изменения, когда пользователь работает из визуальной оболочки: система заполняет сама все необходимые поля и делает соответствующие привязки, однако ничего не мешает разработчику постоянно обращаться к данным свойства, внося ручные корректировки (благо ClearCase позволяет изменять любые свойства любого объекта как из командной строки так и визуальном режим, пользуясь обоими в зависимости от необходимости). Подобный интеллект отсутствует в командной строке, что обязывает пользователя к более формальному отношению ко всем создаваемым объектам. Если попробовать вызвать из оболочки свойства созданного View можно увидеть на вкладке "Config Spec" следующую информацию о состоянии элементов:

element * CHECKEDOUT 

element * /main/LATEST 

Данные описания являются стандартными и создаются для всех видов неявным образом самой программой.

Если возникнет необходимость добавить какой либо новый (пока только подконтрольный) элемент (загрузить его), необходимо добавить к спецификации третью строку со следующим содержанием: "load \app_vob\src", что позволит подключить к виду всю папку "src" со всем ее содержимым (на основе репозитория "app_vob").

Это то, что касается полуручного ввода. В режиме чистой командной строки необходимо воспользоваться командой "EDCS", набрав ее находясь в директории, ассоциируемой с видом (в нашем случае это c:\snapa). В результате появится окно, в которе можно внести соответствующие спецификации. Если же Вам нужна чистая командная строка, то необходимо заранее подготовить файл со спецификацией и передать путь к нему, в качестве ключа к "EDCS" (например edcs c:\my_spec).

Любое обновление данных производится командой "update", находясь при этом в директории со Snapshot View.

Для получения информации о списке всех View, используемых в данный момент в системе необходимо воспользоваться командой "lsview", которая выводит собственно список видов с полными именами и месторасположением. Отличить Dynamic от Snapshot можно по наличию звездочки перед именем вида (присутствует только у Dynamic View).

Рассмотрим все основные возможности видов:

• Виды (Views) строятся для работы над проектом
• Бывают двух типов: Snapshot и Dynamic
• Snapshot создает на локальном компьютере директорию, куда переносит физически все подконтрольные файлы, что позволяет разработчику скопировать все необходимые файлы проекта для работы на дому, с последующим включением их обратно в общий проект. Работает на всех операционных системах.
• Dynamic позволяет подключаться ко всем активным репозиториям, получая исчерпывающую информацию о текущем состоянии проекта, но работает только на UNIX и Windows NT (2000)
• У каждого вида есть настраиваемый (изменяемый) набор свойств
• Во время параллельной разработки создаются виды на базе установленных профилей
• Все операции по контролю данных производятся только через виды

К сожалению, подробное описание функциональности любого программного обеспечения, а продукта ClearCase особенно, выходит за рамки статьи. Мы не сможем подробно остановиться на создании видов, поскольку это непочатый край работы. Весь материал, изложенный на данных страницах, носит ознакомительно-показательный характер и направлен на популяризацию продукта Rational ClearCase. Соответственно, за рамками данной статьи осталась параллельная разработка на основе профилей и проектные VOB'ы. Я надеюсь устранить данный недостаток в последующих статьях, если хватит времени и сил…

Часть 3. Контроль над данными

После создания всех репозиториев и видов настало время попробовать установить файл под контроль программы ClearCase. Как отмечалось ранее, ClearCase в плане контролирования данных способен не только на простой файловый контроль, когда отслеживается изменение одного конкретного файла, но и так называемый контроль за средой, при котором программа начинает контролировать состояние директорий и групп файлов, что помогает разобраться с тем, кто, когда и какой файл внес в проект. Данный аспект можно и нужно отметить как особо важный и сказать, что ClearCase действительно справляется с поставленной задачей.

Итак, каким образом можно ставить файлы под контроль? Все необходимые для этого файлы могут быть скопированы в построенные виды и уже в них поставлены под контроль. Существуют всего три операции, проводимые над данными:

Постановка под контроль (Add To Source Control). Данная операция является первичной. Основная ее нагрузка - декларация того, что тот или иной файл будет взят под контроль и не более того.

Check-in. Поставить под контроль. На этот раз - зарегистрировать файл и вывести ему в древовидной структуре место. Данная операция является стандартной для любых действий, связанных с контролем данных. После задания файлу подобной команды ClearCase в репозитории создаст (закроет) версию файла, которую уже нельзя отредактировать, поскольку он автоматом получает атрибут "read only".

Check-out. Не менее стандартная команда, выводящая за рамки контроля файл с целью создания новой версии. После введения данной команды на дереве появляется новое отделение без присвоенного номера, как бы показывающее, что файл уже подлежит изменениям. Ответвление получит новую цифру версии сразу же после активации Check-in для конкретного файла.

Что же дает обыкновенному разработчику ClearCase в плане контроля изменений:

1. Возможность поставить под контроль абсолютно все: начиная с файла и заканчивая окружением проекта, в том числе древовидной структурой
2. Для каждого подконтрольного элемента рисуется дерево версий, которое на любом этапе разработки можно проанализировать
3. Имеется возможность производить слияния нескольких версий одного файла или структуры окружения
4. Возможность сравнения версий

К сожалению, все операции со слиянием и сравнением доступны только для известных форматов файлов, в которые, естественно, не входят исполняемые, объектные, графические… - естественно, файлы данного типа можно ставить под контроль и хранить вер-сии, но они будут, подобно амебе, существовать без возможности аналитического анализа. ClearCase'ом понимаются текстовые файлы, а также, файлы FrontPage и Word.

Дерево версий, полученное для файла, позволяет легко отследить, кто, когда и для чего создал ту или иную версию. При необходимости менеджер проекта способен создать из двух и более релизов один, объединяя самые последние изменения. Естественно, что ClearCase не производит никаких самостоятельных слияний и сравнений, а только указывает разработчику на их разность, возлагая на него весь интеллектуальный труд.

Используя ClearCase, все участники проекта могут хранить и ставить под контроль собственные данные, создавая необходимые директории. ClearCase позволит им работать только с последними (утвержденными) версиями файлов.

На данном этапе работы удобно использовать две программы из состава ClearCase: ClearCase Detail и VOB Administration Browser. Первая из них представляет собой полнофункциональную консоль работы с данными. То есть здесь находятся все средства управления, которые только могут пригодиться в работе над проектом в целом. Здесь и опера-ции контроля, и вызов менеджера объединений, и вызов дерева версий, а также многое другое - в общем, полный комплекс операций над данными. Вторая программа, конечно, не совсем подходит под контроль, однако показывает всю статистику проекта.

Говоря о методологии контроля, нельзя не отметить наличие такой мощной функции программы, как создание ответвлений (Branches) на дереве версий, что делает возможным на время выйти из общего русла проекта, доработать нужный файл, а потом на его основе либо создать новый, либо влить в существующий в проект. Программа позволяет создавать неограниченное количество ответвлений от одного подконтрольного элемента от одного до бесконечности... Правда, и здесь есть небольшие ограничения, поскольку в ClearCase живут, порой абсолютно независимо, два раздела: графический интерфейс и командная строка. Так вот, множественные ответвления для элементов возможно создавать только из командной строки, а из графической возможно лишь создание основного ответвления с условием обязательного завершения и только для вида в целом. Такой ограничительный подход к полнофункциональной реализации имеет место быть, поскольку позволяет не совсем сведущему человеку заботиться о большом количестве направлений в проекте: каждому по способностям.

От общей теории перейдем к конкретному рассмотрению возможностей ClearCase в плане построения деревьев версий и постановки данных под учет. И как обычно, начнем с описания графических (визуальных, интуитивно понятных) свойств.

ClearCase Detail

Данный модуль можно и нужно считать основным при работе в ClearCase, поскольку именно через консоль Detail можно получить доступ ко всем функциям продукта по управлению версиями и конфигурациями.

Рис. 7

На рисунке 7 показан вид данной консоли после ее вызова. При беглом осмотре его можно сравнить с тем видом, который по обыкновению выводит обычный Explorer. Обратите внимание на левую часть окна, там выведен полный список всех дисков в системе. В имени некоторых присутствует слово view, указывающее на то, что данный диск является динамическим и виртуальным с файловой системой MVFS (см. выше). Как уже говорилось ранее, в каждый динамический вид автоматически включа-ются все репозитории (VOB), что и видно на правой части ClearCase Detail: здесь есть упоминание имен всех трех присоединенных VOB. Специфический значок, показанный слева, указывает на то, что данный элемент находится под контролем и имеет статус "CHECK IN", находясь под контролем ClearCase. Далее в окне выводится некоторая служебная информация о теку-щем состоянии репозиториев.

Технология хранения версий позволяет команде разработчиков независимо друг от друга или совместно ра-ботать над одним и тем же файлом. А под занавес и объединить его с главным. При подобном подходе в ClearCase необходимо создать ответвление от текущей версии, дав ему имя. Я заранее подготовил файл 900.txt, поставил под контроль и произвел некоторые изменения, включающие создание ответвлений. Результат построения дерева для данного файла вы можете посмотреть на рисунке 8. Анализ выведенной информации можно описать так:

• Данный вид построен на базе подготовленного профиля. Об этом говорит ответвление Asteroid. Структурная ветвь main представляет основу, стержень проекта, куда разработчики могут вливать собственные версии.
• Глаз на рисунке показывает на ту версию, которая будет изменяться, если в виде к файлу 900.txt применить команду "check-out".
• От третьей основной версии отходят два ответвления: CC_test и CC_test_99
• Первую из них редактировали дважды, а вторую трижды.

Рис.8

Итак, незаметно мы и подобрались к самому интересному - к параллельной разработке. На данном дереве были созданы два ответвления (CC_test и CC_test_99), которые позволят двум участникам проекта независимо друг от друга править указанный файл. Количество ответвлений можно сделать отличным от двух, как в большую, так и в меньшую сторону.

Для того, чтобы отредактировать файл в конкретной ветви, его необходимо вывести из состояния check-in в состояние check-out. Сделать это можно при помощи правой клавиши мыши, нажав ей на имени соответствующей ветви. Результатом будет добавления пустого кружочка к соответствующей ветви дерева, перевод "глаза" на новую версию и замена файла 900.txt в виде с версии 3 (на ответвлении "Asteroid"), на новую. Файл нужно отредактировать и вновь поставить под контроль. Результатом действия команды check-in будет: генерация новой версии (пустой кружок получит цифру), переезд "глаза" в основную версию (3), возвращение в вид прежнего содержимого файла 900.txt (соответствующего третьей версии).

На дереве версий можно расставлять и задавать метки для разных версий. Правда, ClearCase достаточно оригинально расставляет метки: ему сначала нужно ввести имена всех меток с комментариями, а уже затем расставлять их. Логика странная, но уже неизменная.

Для версий допустимы еще две мощные функции - это сравнение и слияние версий. Методом сравнения можно выяснить все отличия, которые имеются у двух версий, для чего необходимо пометить их и вызвать менеджер сравнений (рис 9). В окне отражаются две версии одного файла, где можно спокойно сравнить их. Специальными значками ClearCase подсвечивает новые и измененные строки. Пользуясь кнопками "next" и "previous", можно путешествовать по всем изменениям, отслеживая их количественно и качественно.

Рис. 9

Для слияния версий необходимо воспользоваться менеджером слияний (merge manager), который, как и в случае со сравнением, позволит увидеть разницу в двух файлах и объединять необходимые строки, создавая на базе двух файлов один новый. На рисунке 10 я сделал абсолютное слияние. Естественно, возможны различные варианты слияний, например из разных видов, построенных на разных профилях, файлы и директории можно сливать по их именам, по меткам, и т.д. Но в данном случае проще сделать так, как показано на рисунке. Как уже говорилось выше, сравнивать и сливать можно не только содержимое файлов, но и состояние директорий проекта, когда, скажем, один из разработчиков включил в проект несколько новых файлов.

Рис. 10

Если довести ситуацию со слияниями до логического завершения (для получения новой версии на ветви main), можно еще слить версии до получения нужной версии на дереве. Примерный вид такого множественного слияния показан на рис 11. Как видите, все изменения, внесенные нами, отразились на дереве версий достаточно отчетливо:

• 3 версия с ветви СС_test_99 объединилась со второй на ветви СС_test, образовав третью. На рисунке данный переход показан красной стрелкой.
• Далее произошло объединение полученной версии с третьей на ответвлении "Asteroid", также образовав новую, четвертую версию.
• Под конец полученную версию файла объединили с ветвью "main"

Командная строка

Рис.11

По традиции рассмотрим выполнение описанных функций из командной строки, а для начала научимся ставить файлы и директории под контроль. Для этого необходимо командой "copy" скопировать все необходимые файлы с локального диска на виртуальный (в нужный вид), после чего воспользоваться командой mkelem, для установки файла под контроль (Add To Source Control). Последовательность действий такова:

Сначала выполняем Check-out для директории, куда был помещен файл (подобный шаг нужен для того, чтобы запротоколировать вхождение нового файла в проект) при помощи команды "cleartool CO -nc .". Следующая по счету команда должна добавить к проекту скопированный файл (как говорилось ранее, все файлы представляют собой разновидность элементов), а делается это при помощи следующей команды "cleartool mkelem 900.txt".

И только после такой последовательности действий можно вернуть под контроль директорию ("cleartool ci -nc .") и поставить под контроль файл 900.txt ("cleartool ci -nc 900.txt"). Следует отметить одну общую особенность при постановке файлов под контроль: программа перед тем, как установить файл, проверяет - изменился он или нет по сравнению с предыдущей версией. Если ДА - файл ставится под контроль без проблемных, лишних вопросов. Если НЕТ, то по умолчанию ClearCase откажется устанавливать файл под контроль.

При таком развесистом дереве версий, которое было создано для файла 900.txt, очень трудно разобраться в деталях без соответствующих комментариев (меток). Для решения подобной проблемы служат две команды: mklbtype и mklabel.

Mklbtype создает метку с указанным именем, но ничему ее не назначает. Mklabel присваивает созданную метку конкретному элементу.
Например:

Mklbtype my_label
Mklabel my_label \tuta\900.txt@@\main\asteroid\ClearCase_test\0

Обратите внимание на второй параметр команды Mklabel, в котором описывается путь до нулевой версии файла 900.txt. Такую нотацию для записи пути к определенной версии элемента мы и будем использовать в дальнейшем.

Удаляет метку команда rmlabel, в которую необходимо передать все те же параметры, что и в Mklabel.

Создание простых ответвлений также не очень сложно. Для данных операций существуют две команды: mkbrtype и mkbranch.

Исходя из предыдущих примеров и из оригинального интеллекта программы ClearCase, перед созданием ответвления необходимо внести и зарегистрировать его имя командой "mkbrtype -nc new_01". Данная команда никого не к чему не обязывает, попросту регистрирует имя ответвления, физически его не создавая.

Сложнее дело обстоит с физическим ответвлением, поскольку перед его созданием необходимо точно определить, от какой версии создается ветвь. Если ничего специального не указано, создастся ответвление от текущей версии (подсвеченной глазом), в противном случае, когда необходимо создать ветвь не для текущей версии, можно воспользоваться указанием пути к конкретному элементу, так как делалось выше. Позволю акцентировать свое и ваше внимание на одну особенность в создании ответвления: элемент, для которого создается ветвь, должен обязательно находиться в состоянии "check-in".

Например:

     mkbranch new_01 900.txt@@\main\Asteroid\cc_test_99\0

Как видно из параметров, mkbranch создаст ответвление с именем new_1 (рисунок 12 наглядно покажет действие данной команды) для элемента 900.txt, находящегося по адресу \main\Asteroid\cc_test_99\0. Хочу немного себя поправить, добавив к сказанному одну деталь: все демонстрируемые команды набираются из интерпретатора команд cleartool, а текущей является директория в динамическом View, куда помещен подконтрольный файл 900.txt. Уточнение приведено не случайно, поскольку находясь в ином каталоге необходимо задавать полный путь к элементу. В моем случае он выглядит следующим образом: "m:\99-09\tuta\900.txt@@\main\Asteroid\cc_test_99\0", где: "m:" - имя виртуального диска, созданного видом, "99-09" - имя самого вида, "tuta" - имя VOBа.

В вышеописанном примере мы ввели достаточно сложную команду создания ответвления. Подобные ветви, как показывает практика, создаются не так часто. Обыкновенно создается ветвь от текущего элемента: mkbranch new_01 900.txt, - подобная запись гораздо проще воспринимается и запоминается.

Рис.12

Производить слияния версий можно и из командной строки, правда, контролировать результат проще графически, но…

Создание объединения из командной строки сводится к выведению конкретной версии файла (реципиента) в состояние check-out, после чего командой "merge" указывается его имя и путь к тому элементу, из которого будут браться данные для объединения (донора). В нашем случае можно вывести любую версию в состояние check-out, после чего выбрать исходный элемент и запустить все на исполнение.

Например:

     Co -nc 900.txt@@\main\Asteroid\cc_test\2
     Merge -to 900.txt 900.txt@@\main\Asteroid\cc_test_99\2
     Ci -nc 900.txt

Результатом работы команды будет создание объединение двух версий файла с разных ветвей. При подобном объединении ClearCase различает два типа объединений: тривиальные и нетривиальные. В случае с тривиальными, то есть с теми, которые можно просто объединить, не задавая вопросы пользователю (например, в новой версии к файлу добавлены две новые строки, естественно при подобном слиянии вопросов задано не будет и слияние произойдет достаточно быстро). С точностью до наоборот обстоит с нетривиальными сравнениями, когда два объединяемых элемента содержат большие расхождения, что приводит к возникновению большого количества вопросов, на которые ClearCase сам не ответит, возложив всю рутину по слиянию на плечи пользователя.
Подведем итог полученной информации:

• Каждый файл или директория представляется в ClearCase в виде элементов
• Каждый элемент имеет свою историю
• Каждый элемент имеет версию и дерево версий
• Любые операции над версиями производятся при помощи команд Check-in и check-out
• Элемент, находящийся в состоянии Check-in невозможно редактировать
• ClearCase позволяет создавать ответвления от конкретной версии для параллельной разработки
• Функция merge позволит объединить две версии одного элемента, создав третью
• Количество ответвлений ничем не ограничивается
• Ответвления бывают двух типов: глобальным и локальным
• Глобальное ответвление делается для всех файлов, составляющих проект
• Локальное возможно создать только для отдельного элемента

Дополнительные возможности ClearCase

MultiSite

Как известно: аппетит приходит во время еды, стало быть то, что не вызывало интереса до начала описания, должно вызвать его в процессе чтения, на худой конец после него! В предыдущих частях, мы рассмотрели все основные возможности работы программы ClearCase, коснувшись понемногу всех главных аспектов его использования. Естественно, не идет и речи о каком бы то ни было приемлемом по полноте описании данной программы, так как для полного описания потребуется не статья, а учебник, и даже не один. Ведь по большому счету, цель данной статьи - ознакомление конечного пользователя с возможностями продукта: введение в предметную область, общее описание возможностей… и так далее. Начиная с данной главы, мы попытаемся описать некоторые возможности пакета ClearCase, которые являются весьма и весьма интересными и познавательными, но могут и не использоваться в повседневной жизни конкретным разработчиком.

Как известно, интерес к продукту во многом зависит не только от его прямых возможностей, но и от того окружения, которое способствует его нормальному функционированию. Скажем, графический интерфейс пришел на смену командной строке, что способствовало, в свою очередь, интересу со стороны пользователей к вычислительной технике. Так получается и в данном случае: ClearCase в чистом виде - это система контроля версий и конфигураций, причем очень хорошая, но… Разработчик пред началом ее использования должен знать - совместно с чем она способна работать, какие у нее сервисные функции и пр. Повторюсь еще раз: идеальное исполнение прямых обязанностей, возложенных на продукт, не есть самое главное.

Ниже мы опишем возможность ClearCase, помогающую вести работу над проектом группам разработчиков, чьи офисы находятся на значительном удалении друг от друга (в другом районе, городе, стране, планете…).

MultiSite - специальный модуль, дополнительно входящий состав ClearCase и позволяющий обмениваться данными нескольким (двум и более) командам разработчиков. Данный модуль неявно присутствует в любой поставке ClearCase за исключением Attache, и начинает свою работу только после введения специального ключа, дающего "добро" на все возможности репликации проектов.

К сожалению, выявить присутствие данного модуля весьма проблематично, поскольку он не имеет графического интерфейса и практически никак не указывает на свое присутствие в системе. Отчасти такое поведение можно считать недостатком, но при детальном углублении в суть проблемы выясняется, что явное отсутствие модуля не такая большая проблема, в силу тех функциональных обязанностей, которые возложены на MultiSite. Основным и единственным предназначением данного модуля является генерация и отправка синхронизационных пакетов - реплик, по указанным IP адресам. Согласитесь, данная функция абсолютно не нужна большинству участников проекта. Подобная идеология и легла в основу "невидимости" модуля: с глаз долой, из сердца вон!

И по сложившейся традиции давайте на конкретных примерах разберем функциональные возможности MultiSite, но для начала опишем основные возможности и особенности программы:

• Используется для передачи реплик по указанному IP адресу
• Синхронизирует и передает реплику (копию VOB)
• Отдельно передает права на изменения отдельных элементов
• Осуществляет автоматическую или ручную синхронизацию реплицируемых пакетов (прием/передача)

Настройка модуля MultiSite производится из единствнного графического аппета, имеющегося в его распоряжении. Местоположение данного модуля столь же неявно, как и само присутствие MultiSite. Апплет находится в ControlPanel и представляет собой настроечное окно. Рисунок 13 показывает вид данного окна.

Рис. 13

Обратите внимание на простоту и небесную лаконичность данного диалога - в нем нет ничего лишнего!

Получим развернутое представление о следующих полях:

Maximum Packet Size - максимальный размер передаваемой реплики. Задает верхнюю планку на размер пакета.

Administrator Email - адрес почты администратора. В случае всех неудач в отправлении пакета система сообщает все по введенному электронному адресу, что позволяет удаленно контролировать процесс передачи реплик.

Staorage Clases - здесь задаются настройки классов. В частности задаются наименования классов передачи, которым задаются специфические директории по отправке и приему реплик. Поскольку механизм работы MultiSite сводится к отправке реплик из специальной директории, то неплохо, например, для разных проектов создавать разные клас сы, для каждого назначая отдельные каталоги во избежание путаницы. Впрочем, "желательно" - не значит "обязательно".

Routing Information - адрес сервера для передачи пакета. Здесь необходимо указать IP адрес сервера, для которого производится передача пакета. Количество передаваемых адресов ничем не ограничено. MultiSite последовательно перешлет по каждому из них сгенерированную реплику. Очень любопытным представляется пункт "Next Routing Hop", в котором дается адрес следующего сервера, ведь передача возможна не только по принципу "от одного ко многим", но и "получил сам - передай другому". Графически данные способы отображены на схемах №№1,2. Естественно, данные примеры достаточно тривиальны, реальные же схемы могут отличаться от искусственных большей ветвистостью, совмещая различные комбинации обоих способов передачи.

Создание и передача реплик:

Вся работа с MultiSite осуществляется через командную строку интерпретатора MultiTool.exe. По сравнению с ClearTool, здесь команд существенно меньше, как по описанию так и по факту. Действительно важных, или скажем, часто используемых, всего 4-5, правда, их синтаксиса хватило бы на десяток простых.

Попробуем описать, что в теории может делать MultiSite и как в принципе создается и передается реплика. Схему передачи можно выразить следующим образом:

1. При помощи команды mkreplica создать реплику (на передающем сервере). Наступает очень тонкий и интересный момент. В зависимости от специального селектора данная команда может по-разному создавать реплики. Например, есть возможность мгновенной и отложенной передачи реплики, когда пакет автоматически кладется в директорию, указанную в графическом аплете, и далее отправляется по указанному адресу. Но самое интересное даже не в этом, mkreplica способна создать реплику и сохранить ее на любом носителе - от дискеты до DVD. Подобная практика применяется редко, но она существенно расширяет способности продукта. Ну, скажем, стандартная реплика никак не шифруется (за исключением простенького паролирования), соответственно любой желающий может перехватить ее и узнать все секреты Ваших разработок. Вот здесь и может пригодиться такой способ генерации, при котором Вы получаете файл, сами его шифруете и сами отправляете в место назначения любым известным науке способом. Правда, в таком случае, словосочетание "автоматическая синхронизация" слегка теряет свой смысл!
2. На принимающем сервере также ввести mkreplica с параметром "import". Данная команда набирается только один раз при первичной передаче пакета. Все дальнейшие передачи называются синхронизационными, а для их передачи и приема используется команда SyncReplica, которая не создает полную копию репозитория, как в случае с mkreplica, а лишь генерирует новую реплику, содержащей только изменения по отношению с предыдущей синхронизацией. Так вот, при первом импорте CC создаст VOB с тем именем, которое указано при импорте. Для использования пакета необходимо его смонтировать и построить требуемые виды.
3. Измененный, отреплицированный VOB возвращают обратно, передавшему серверу.

Прелесть MultiSite при синхронизации реплик заключается в том, что если за время, прошедшее с момента передачи предыдущей реплики, VOB никак не был изменен, то и реплика не будет создаваться и пересылаться, поднимая до поднебесья трафик компании.

Отдельно хочется поговорить о передаче прав на изменение (команда "chmaster"), что позволит не только реплицировать копию VOB, но и передать права на ее правку. Права можно передать как на один элемент, так и на целую группу.

Во избежание путаницы, связанной с тем кто, когда, и для кого создавал реплику, MultiSite предоставляет полную статистическую выкладку по синхронизациям для каждого конкретного VOB, при помощи команды "lsreplica".

Как видите, MultiSite продукт весьма нужный и весьма важный в тех случаях, когда необходимо связать в один проект удаленные группы разработчиков, которые смогут, пользуясь всеми преимуществами программы ClearCase и не выходя из офиса, создавать и контролировать разрабатываемое программное обеспечение.

Интеграция с Visual Studio

Компания Rational очень тесно сотрудничает с Microsoft в области информационных технологий, посему все программные продукты от Rational тем или иным образом интегрируются в первую очередь со средами разработки от MS.

Рис.14

Соответственно, тесная интеграция поддерживается для Visual C++ и Visual Basic. Пользователь, находящийся в данных средах, получает полный набор средств для версионного контроля, не выходя из среды разработки. В принципе, любой программист может разрабатывать что угодно в любой среде, но все операции по контролю производить из ClearCase Detail, контролируя самостоятельно все состояния для каждого отдельного элемента.

При "правильно" установленном Visual Studio, возможна работа утилиты сборки из состава ClearCase. Под "правильной" установкой подразумевается подключение
возможности компиляции из командной строки (на одном из последних шагов Visual Studio спросит о создании соответствующих изменений).

Интеграция с VS состоит в появлении ряда функций в подпункте Source Control меню Project, и позволяющий осуществлять обращения к ClearCase не напрямую, а через данный пункт (см. рисунок 14). Как видно из содержимого окна, подобная интеграция подразумевает использование наиболее употребительных функций, ежедневно необходимых для полноценной работы членов команды. Интересный пункт, о котором мы ранее не говорили, - "Get Latest Version", позволяющий получить доступ к последней версии. Необходимость использования данного пункта возникает при работе со Snapshot Views, когда есть необходимость обновлять (синхронизировать), при использовании же динамических видов необходимость в этом пункте отпадает, да и ClearCase, не позволит воспользоваться командой.

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

1. Создается репозиторий, на его основе строятся виды с использованием различных профилей
2. Создается древовидная структура в виде. Следуя методологии Rational, каждому члену

   рис. 15

   команды - свою директорию (менеджерам, разработчикам, техническим писателям…)
3. Для разработчиков Rational рекомендует использовать отдельные директории для кода, библиотек, исходных текстов, заголовков. Здесь нет ничего нового и неожиданного - того, чем никто раньше не пользовался бы. Это все те же: SRC, INCLUDE, LIB, BIN… Но раз мы пользуемся продуктами и методологиями Rational, то не нужно раздражаться от лишних напоминаний о грамотном построении проекта
4. Все директории, созданные для проекта, также необходимо ставить под контроль, поскольку, как
   говорилось выше, ClearCAse это не только версионный контроль, в чисто файловом исполнении, он способен на большее, например, отслеживать и хронологизировать миграцию проектных файлов по директориям
5. Любой проект создается в виде (динамическом или снапшот - неважно)
6. Файлы ставятся под контроль либо из ClearCase Detail либо из Visual Studio посредством контекстного меню из Workspace
7. Дальнейшую же работу можно также построить полностью без выхода из Visual Studio либо при помощи макросов, либо настройкой Tools, соответствующими вызовами ClearCase

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

ClearCase имеет в своем арсенале такой мощный механизм, как сборщик проектов, позволяющий компилировать и собирать проекты. Утилита, помогающая в данной работе носит название "omake"

Рис.15(а)

. Ее основная задача - сборка проекта на основе Make-файла. Прелесть же заключается в том, что в нем (Make-файле) можно включать в компиляцию не только последние версии файлов, как это принято, но и любые другие версии, к которым явно указан путь по ответвлениям (выше в 3 части, мы уже говорили о пути к элементу). К сожалению, данная утилита достаточно объемна, и под нее будет выведена если не новая статья, то новая глава - это уж точно! В данном контексте мы просто рассмотрим, как ее вызвать из Visual Studio с обычным набором параметров - без излишеств.

Выполнить это несложно, необходимо лишь воспользоваться инструментарием, имеющемся в составе Visual C++, по вызову внешних модулей. Вызываем Tools-->Customize, создаем новую запись с именем "omake" и вносим информацию, как показано на рисунке 15. В качестве аргументов, передаем имя рабочей директории и имя проекта. Для работы всего хозяйства в Visual Studio необходимо построить MAK-файл. Делается это при помощи "Project->Export MakeFile". После чего в проектном каталоге появляется Make файл, соответственно оформленный и готовый к использованию. Преимуществом "omake" можно считать его независимость относительно используемого компилятора. То есть, возможно использование любого компилятора командной строки, собирающего проекты по make-файлам.

На следующем рисунке (15а) показан пример внесения новой команды, в инструментарий Visual Studio, команды модуля MultiTool, позволяющей получить список всех реплик для указанного VOB.

Как видите, ClearCase достаточно тесно встраивается в Visual C++, добавляя к стандартным возможностям продукта мощную систему версионного контроля для крупных команд. В тех же случаях, когда отдельному разработчику недостает определенных функций, всегда есть возможность дополнить стандартный инструментарий собственными расширениями, так, как показано выше.

Генерация отчетов

Еще одна немаловажная задача, которую необходимо решить при работе над проектом - это написание проектной документации и различных отчетов. Имея в своем распоряжении увесистый репозиторий, массу видов и подконтрольных элементов, будет трудно составить вручную отчет, просматривая все данные с экрана компьютера. Такую работу можно считать непродуктивной и неправильной, хотя и имеющей право на существование, ведь не всем доступны такие мощные и продвинутые методологии и инструменты, которые предлагает Rational Software. Дело в том, что для такой цели как генерация отчета существует продукт SoDA, встраиваемый в MS Word. Он позволяет строить отчеты по заранее заготовленным шаблонам. Отчет строится в соответствии с выбранным продуктом (поскольку генерация отчета для ClearCase вещь частная). Продукты, поддерживаемые генератором отчетов: Rational Rose, Requisite PRO, ClearCase.

Рис.16

Это значит, что любой человек, взявшийся за написание проектной документации или отчета получает универсальный инструмент, работающий в самом популярном текстовом редакторе и позволяющий легко получить шаблон для одной из программ от Rational и добавить в него комментарии сообразно поставленной задаче.

Попробуем в режиме наглядной агитации рассмотреть возможности SoDA, годящиеся для использования совместно с ClearCase, для чего создаем новый репозиторий, виды, вносим некоторое количество файлов. Для создания шаблона вызовем приложение "SoDA getting Started". Поскольку сама сода - продукт встраиваемый в Word и неспособный функционировать отдельно, то SoDA автоматически вызовет сам Word, и ссылку на себя поместит в верхнее меню. Результатом выполненых действий будет появление диалога с предложением выбора типа шаблона, который предстоит генерировать. На рисунке 16 показан внешний вид окна с подобным запросом. В случае с ClearCase доступны следующие виды заранее составленных шаблонов, каждый из которых составляет специфический отчет:

Activity

• Element - генерирует шаблон для отдельного элемента. Для генерации необходимо указать путь к элементу, для которого строится отчет.
• Region - отчет о состоянии репозиториев для отдельного региона
• Version - отчет по версиям
• Vob - отчет по содержимому репозиториев

По своим возможностям сода, конечно же, не самый насыщенный инструмент в линейке продуктов Rational, но четко справляющийся со своими прямыми обязанностями - с генерацией отчетов.

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

Ниже приводится пример сгенерированного отчета по состоянию элемента. В качестве элемента используется файл project_so.h. Внимательно всмотритесь в отчет, по-моему, его даже не нужно комментировать - все ясно, понятно и наглядно!

ELEMENT

Report on Element Z:\Tempa\src\project_so\project_so.h@@

   Path: Z:\Tempa\src\project_so\project_so.h
   Description: 
   Element Type: text_file 
   Master: N/A 
   Owner: NOVICHKOV\Administrator 
   Is Directory: False VOB
   Name: \Tempa 
   Date Created: Friday, April 07, 2000 13:28:59 
   Created By: Administrator 

Versions

   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\0 Number: 0 
   Is Latest: False 
   Description: 
   Date: Friday, April 07, 2000 13:28:59 
   User Name: Administrator 
   Labels: Branches: 
   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\1 
   Number: 1 
   Is Latest: False 
   Description: 
   Date: Friday, April 07, 2000 13:32:40 
   User Name: Administrator 
   Labels: Branches: 
   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\2 
   Number: 2 
   Is Latest: False 
   Description: Second 
   Date: Friday, April 07, 2000 13:36:10 
   User Name: Administrator 
   Labels: Branches: 
   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\3 
   Number: 3 
   Is Latest: False 
   Description: 
   Date: Friday, April 07, 2000 13:40:15 
   User Name: Administrator 
   Labels: Branches: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\alex

   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\alex\0 
   Number: 0 
   Is Latest: False 
   Description: 
   Date: Friday, April 07, 2000 13:42:41 
   User Name: Administrator 
   Labels: Branches: 
   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\alex\1 
   Number: 1 
   Is Latest: True 
   Description: ALex 
   Date: Friday, April 07, 2000 13:43:43 
   User Name: Administrator 
   Labels: Branches: 
   Name: M:\First_dyn_view\Tempa\src\project_so\project_so.h@@\main\4 
   Number: 4 
   Is Latest: True 
   Description: Соединение 
   Date: Friday, April 07, 2000 13:45:41 
   User Name: Administrator 
   Labels: Branches: 
 

Приложения

Рано или поздно, работая над программным проектом, группы программистов, тестировщиков и менеджеров проекта, сталкиваются с проблемой усложнения отслеживания версий файлов проекта, внесения в них изменений, и получения детализированного состояния текущего проекта: "КТО и КОГДА". Ведь чем больше проект, тем больше времени разработчики тратят на согласование изменений в исходных текстах, создание деревьев версий модулей и отдельных файлов проекта, написание проектной документации, обновляемой по ходу проекта.

Это лишь малая часть всех "ужасов", сопровождающих команду разработчиков на всем жизненном цикле проекта: от идеи до поддержки готового программного продукта. А малая она еще потому, что здесь не получили отражение такие мелочи как: время разработки проекта и стоимость оплаты труда группы разработчиков. Ведь ни для кого не секрет, что редкий проект укладывается в запланированные сроки, и уж совсем большая редкость - когда проект выходит в срок, и в нем реализованы все запланированные идеи!

Компания Rational для решения всех описанных вопросов выпускает целый спектр программного обеспечения, предназначенного для заполнения всех экологических ниш, связанных с разработкой - попросту предоставляя конкретный продукт для конкретного этапа в создании программного продукта (реализации проекта).

Ниже мы рассмотрим систему конфигурационного и версионного управления ClearCase. А точнее его новую версию - 4.0. Как и все предыдущие реализации данного продукта, новая версия представляет собой высококачественный продукт.

В новой версии ClearCase получил более продвинутый графический интерфейс, в частности - новую консоль администратора (VOB Administrator), как и раньше не остались без внимания и любители командной строки - в новой версии добавлены новые команды, облегчающие работу с VOB и VIEW, а также расширенная справочная система, доступная из командной строки (команда man). Нелишне будет отметить новый формат VOB, призванный облегчить администрирование и контроль файлов (формат VOB задается отдельно, Вы сами вправе выбрать его тип: 4.0 или 3.2.1).

Новшеством для ClearCase также можно считать появившуюся возможность получения доступа к файлам проекта через Internet, для чего на сервере необходимо установить одну из программ для организации WEB сервера (для тестирования мы применяли Internet Information Server версии), а на клиентской части достаточно иметь, собственно, ClearCase и любой броузер и подключение к сети.

Компания Rational достаточно много времени уделила улучшению интеграции своих продуктов со средствами разработки и документирования, поставляемых Microsoft. В частности ClearCase теперь встраивается в Microsoft Word, позволяя производить все операции сравнения и сливания над всеми форматами файлов, которые понимает Word. И еще важное новшество, которое поможет WEB-разработчикам - ClearCase тесно интегрируется с MS FrontPage, понимая файлы *.XML, *.HTML.

Отдельно хочется отметить и поощрить стремление компании больше времени уделять графической оболочке без ущерба командной строки. Новая версия позволяет в наглядном режиме работать над проектом, лишь изредка прибегая к помощи командной строки. Субъективно - новая версия создает впечатление хорошо переработанного продукта, направленного на улучшение диалога "человек-машина". Теперь все возможности ClearCase можно понять с первого раза и без особых усилий.

ClearCase 4.0

Поддерживаемые платформы
Windows NT 4.0, Build 1381 (SP3, SP4, SP5)
Windows 2000, Build 2128 (RC 2)
Windows 95/98 (все версии и релизы, но только ClearCase - без MultiSite)

Поддерживаемые файловые системы
Windows NT 4.0 - FAT, NTFS, LANMAN, NFS
Windows 2000 - FAT, FAT32, NTFS, LANMAN
Windows 95/98 - FAT, FAT32

Unified Change Management

Данная реализация поддерживает модель out-of-the-box, включающая мощный набор инструментов для управления и конфигурирования среды разработчика. Для менеджеров проекта и интеграторов, UCM автоматически осуществляет политику разработчика.
Поддерживаются следующие концепции:
Activities, Components, Baselines, Projects, Streams, Project VOB

Добавлены новые команды и интерфейс для UCM
Команды: Chbl, lsbl, mkbl….. Всего добавлено 30 команд.
Интерфейс: ProjectExplorer, Create Project Wizard, Join Project Wizard, Deliver (dialog box), Rebase (d.b.), Component Tree Browser, Compare Baselines

ClearCase WEB Interface

Как говорилось выше, в новой версии стало возможно получать доступ к проектным файлам через WEB страницы. Данный способ позволяет подключаться как к Dynamic View, так и к Snapshot View.

Новые типы файлов и программ, поддерживаемых ClearCase
Ниже приведены названия программ и расширения, поддерживаемые ClearCase 4.0
Front Page HTML, HTM, XML
Microsoft Word DOC
Rational Rose CAT, MDL, PTL, PTY, PRP, PRC, SUB

Переработана консоль администратора

ClearCase для Windows NT получил новую административную консоль, которая позволяет легко контролировать состояние проекта на любом уровне иерархии. Новая панель администратора реализована как snap-ins Microsoft Management Console (MMC).

Увеличен кэш для видов

Теперь величина кэшей поднята до 500КБ для 32 битных платформ, и 1000Кб для 64 битных платформ.

Новый формат VOB

К особенностям данного формата можно отнести возможность обработки большого количества записей в базе. Сейчас величина записей составляет 16 миллионов, а размер файлов до двух гигабайт. Также новый формат более тесно сотрудничает с Windows NT, позволяя получать полную сопроводительную информацию о типе файла при просмотре в доменах NT. Старые VOB можно конвертировать в новый тип, при помощи специальной команды.

Доступ к данным без установки ClearCase

Теперь стало возможным получать доступ к файлам проекта без установки клиентской части ClearCase. Такая возможность предоставляется через WEB интерфейс и через удаленный доступ к snapshot видам.

Изменение документации

Реорганизована и реструктурирована документация.

Новое в MultiSite 4.0

Как известно, MultiSite представляет собой специальный модуль, позволяющий регионально удаленным командам разработчиков обмениваться копиями VOB. При этом MultiSite берет на себя синхронизацию посылаемых и отправляемых пакетов (реплик) и передачу прав доступа.

Подробнее о MultiSite читайте в следующих частях, а сейчас, для владеющих продуктом, перечислим новые возможности версии 4.0:

Новый скрипт синхронизации

Теперь стало возможным использовать скрипт "sync_export_list" для автоматического экспорта реплики. В свою очередь, скрипт "sync_receive" позволит автоматически принять реплику. Скрипт присваивает каждой реплике уникальное имя.

Новый механизм синхронизации

Существующий механизм cleartool schedule заменен новым методом "at" для лучшего планирования синхронизаций операций импорта/экспорта.

Добавлены новые команды

Lsepoch и chepoch. Выводят на экран текущее состояние переданной реплики и позволяют обновлять и изменять номера матриц. А команды chmaster и reqmaster теперь доступны из cleartool.

Новые максимальные значения на размер передаваемого пакета

Максимальный размер пакета по умолчанию составляет 2097151Kb Данное ограничение действует при вызове команд mkreplica или syncreplica с ключами -ship и -fship

Ответы на часто задаваемые вопросы по версиям 3.2.1 и 4.0

Вопрос: Под каким сервис паком в Windows NT нормально работает ClearCase 3.2.1?
Ответ: Нормальная работа для данной версии гарантируется при работе только с ТРЕТЬИМ сервис паком

Вопрос: Является ли MultiSite отдельным программным продуктом?
Ответ: Нет. MultiSite является подмодулем программы ClearCase

Вопрос: Опишите принцип работы MultiSite?
Ответ: Работа MultiSite заключается в формировании реплик (копий баз данных проекта), которые могут быть переданы на другой сайт посредством дискет, электронной почты, Интернет. Работа над проектом производится на нескольких сайтах параллельно и независимо. Для синхронизации организуется обмен репликами. Работа с MultiSite осуществляется только из командной строки, посредством нескольких команд.. Реплика может передаваться сразу на несколько сайтов.

Вопрос: Что нужно для того, чтобы заработал MultiSite?
Ответ: Необходимо получить лицензию на его использование (дополнительно к той, которая получена на ClearCase)

Вопрос: Можно ли передавать при помощи MultiSite данные не через интернет?
Ответ: Да, такая функция модулем предусмотрена. По сути, передача через интернет - это всего лишь один из нескольких способов передачи информации. Также передачу можно осуществить через любое запоминающее устройство (отослав, впоследствии носитель с репликой курьером, в указанное место) или электронную почту. Правда, в таком случае, Вы лишаетесь оперативности.

Вопрос: Что такое VOB. Его особенности ?
Ответ: VOB (Version Object Base) - специальная база данных (репозиторий) программы ClearCase. В ней хранится вся информация о текущем состоянии проекта. На физическом уровне VOB представляет собой совокупность директорий и файлов. К сожалению, работа на физическом уровне невозможна, в силу того, что для ведения базы используется внутренний формат базы. Однако для контроля VOB существует более высокий уровень работы: через командную строку илиграфическую оболочку. Любой VOB создается, изменяется и удаляется средствами программы.

Вопрос: Что такое View?
Ответ: View (просмотр) специальное средство, позволяющее вести контроль над репозиторием. Попросту View позволяет производить и контролировать все операции доступные над репозиторием. View позволяет в наглядной форме класть под контроль изменять и редактировать файлы. Причем отображаться на экране будут не все версии отдельного файла, а, например, только последние (либо другая, указанная конкретно).

Вопрос: Какие типы файлов можно ставить под контроль ClearCase?
Ответ: Под управление ClearCase можно ставить текстовые файлы, файлы проектов, объектные файлы… На самом деле, положить под контроль можно практически любой файл (неизвестный заранее СС). В этом случае вы лишаетесь таких мощных возможностей программы как: сравнение и объединение.

Вопрос: Обязательно ли при использовании MultiSite обмениваться полными репликами Vob?
Ответ: Нет. Полная реплика передается только один раз, в самом начале, в дальнейшем же можно и нужно передавать только изменения, касающиеся данного VOB (такой вид реплики в ClearCase носит название SyncReplica - синхронизация). Есть еще и второй способ, при котором MultiSite можно настроить таким образом, что он автоматически будет передавать синхронизационные пакеты. Дабы не повышать трафик MultiSite не отсылает реплики неизменного VOB'а.

Вопрос: Совместимы ли PVCS и CleraCase?
Ответ: Как таковые - НЕТ, но в CleraCase есть возможность конвертации проекта из PVCS

Вопрос: Существует ли какой ни будь встроенный способ шифрования данных при передаче их при помощи MultiSite?
Ответ: Нет, такой возможности - нет. Но так как MultiSite может пересылать пакеты не только напрямую, но и через электронную почту, создавая для начала синхронизационный пакет в виде файла. Так, вот этот файл и можно шифровать любым доступным способом.

Вопрос: Можно ли осуществлять (и при помощи чего) документирование содержимого проекта?
Ответ: Да, можно. Для этого существует пакет Rational SoDA, который и строит подобную документацию на базе установленных шаблонов. Соответственно, исходя из полной совместимости SoDA с MS Word - разработчик получает готовый к дальнейшему редактированию документ в общепринятом формате.

Вопрос: На каких платформах реализован ClearCase?
Ответ: Официальная информация от Rational по поводу версии 4.0:
Compaq Tru64 UNIX;
Hewlett-Packard HP-UX;
IBM AIX;
NCR MP-RAS;
Red Hat Linux;
SCO UnixWare;
Siemens Reliant UNIX;
Silicon Graphics IRIX;
Sun Solaris SPARC,
Solaris Intel;
Windows 95, 98 (только клиентские части);
Windows NT;
Windows 2000;

Вопрос: Какие WEB сервера поддерживаются модулем MultiSite?
Ответ: Поддерживаются:
Apache;
Microsoft IIS;
Netscape

 

• Обратиться в Interface Ltd. за дополнительной информацией/по вопросу приобретения продуктов
• Подробнее о продуктах IBM Rational
• Приобрести продукты компании IBM Rational в электронном магазине ITShop.ru
• Курсы обучения по продуктам компании IBM Rational Software