Кому и зачем нужен ClearCaseАлександр Новичков
Часть 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:
ClearCase тесно интегрируется со всеми инструментальными средствами компании Rational, некоторые из которых дополняют его функциональность. Например, Rational SoDA позволяет менеджерам и администраторам документировать, описывать текущее состояние проекта, основываясь на той информации, которая предоставляет SoDA. Как видно из материала, ClearCase представляет собой серьезный и достойный продукт, помогающий выпускать софтверным компаниям более качественные программные продукты в реальные сроки. Тесная интеграция с наиболее популярными средами разработки приложений делает возможным получать доступ к проектной информации, пользуясь привычными инструментами. ClearCase поддерживает многие платформы, но вся дальнейшая информация в статье будет касаться только его реализации под Windows.
Первый, представлен двумя частями (клиентской и серверной), каждая из них является полнофункциональной, с разницей в особенностях администрирования и лицензирования. Второй вариант - это усеченная версия продукта в которой не реализованы все функции полного продукта. Единственным плюсом Attache является его способность запускаться на платформах: Win3.0, Win3.1, Win95/98/NT. Создание VOBДальнейшее описание продукта пойдет с тематическим разделением. Далее мы примемся описывать наиболее интересные аспекты использования ClearCase в соответствии с планом, приведенном в начале статьи. Данная часть позволит познакомиться Вам с механизмом, составляющим основу ClearCase, - созданием репозиториев, на основе которых строятся дальнейшие отношения с программой. Если вкратце описать принцип работы пользователя в программе ClearCase, то получается следующий алгоритм:
Словесное описание пунктов можно выразить так: создается одна или несколько баз данных (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] Это простейший формат данной команды, в котором рассматриваются следующие настройки: -tag - задает имя VOB \\path - полный путь к создаваемому VOB Рассмотрим, в качестве примера, следующую команду: mkvob -c "alex" -tag \alloiz \\Novichkov\1\alloiz.vbs Описание выглядит следующим образом: создать VOB с именем "alloiz", присвоить комментарий "alex". Хранить репозиторий надлежит в "alloiz.vbs" по указанному адресу к открытому каталогу "1". При верном исполнении всех инструкций, по окончании создания VOB будет выведена статистика (тесно связанная с настройкой конкретного хоста) примерно такого вида:
Теперь необходимо смонтировать VOB командой "mount \alloiz", что приведет к монтированию файловой системы MVFS для VOB "\alloiz" (при безошибочном исполнении команды, выведется следующая информация: "Mounting MVFS filesystem \alloiz") Список всех имеющихся VOBов всегда можно узнать при помощи команды "lsvob". Основные особенности VOB:
Рассмотренный материал является лишь малой частью того, что можно делать с репозиториями. Часть 2. Построение видовVIEWs, изучение основных свойств фильтров просмотра.Второе опорное понятие в ClearCase, без которого невозможна работа в принципе - это View - система видов (представления информации), которая позволяет фильтровать все обращения к VOB, выводя только ту часть из них, которая была определена пользователем. Как уже упоминалось ранее ClearCase, осуществляет контроль над файлами при помощи стандартных операций "check in" и "check out", которые призваны вносить файл в рамки контроля, либо выводить его. View позволяет получать доступ к файлам и данным проекта при помощи стандартных средств работы. Ими могут быть: "проводник", "Word", а также программы, проводящие любые файловые операции. Необходимость использования "видов" очевидна, так как без наглядного представления, данные не могут быть информативными. Если вновь вернуться к понятию фильтра, и посмотреть на View с этой точки зрения, то получается очень интересная картина: ведется проект, в котором скопилось по 10-20 версий каждого файла, и все из них, как положено, находятся в VOB, а работать команде необходимо только со свежей (последней) версией, то налицо проявляется основное (фильтрационное) свойство видов - они позволяют скрыть от глаз конечного пользователя всю кухню (историю создания), выводя на экран только последний релиз и все к нему относящееся. ClearCase имеет возможность работы с двумя типами View, имеющими свою специфику в использовании: Dynamic View и Snapshot View. На этом специфика видов не заканчивается, поскольку каждый из них может строиться на базе профилей пользователей. Профили задаются отдельно, после чего на их основе строят виды. При помощи профилей можно организовать, например, параллельную разработку одного и того же файла разными членами команды разработчиков, после чего можно без особых проблем объединить их в один, и получив таким образом файл, построить на его основе новый релиз. Рассмотрим особенности обоих типов представления:
Как видно из вышеcказанного, оба вида имеют достоинства и недостатки, а посему придется использовать их совместно в зависимости от текущих потребностей. Например, если локальная сеть в организации построена на базе систем Windows NT и 98, то всем разработчикам в W98 придется работать только со Snapshot View. В случае же надомной работы или частых разъездов участников проекта, Snapshot View становятся просто незаменимы, ведь только данный тип представления позволяет получить "слепок" необходимых файлов, скажем, на переносной компьютер и уехать в командировку. По возвращении в офис разработчику останется только подключиться к сети и произвести обновление подконтрольных данных. Динамический способ просмотра, гарантирует Вам наиболее полный охват компонентов проекта, поскольку данный тип вида работает со всеми присоединенными репозиториями. Использование такого метода оправдано для менеджеров проекта, которым, в силу многих причин, необходимо иметь доступ ко всему проекту целиком. Для работы с видами существуют такие стандартные для объектов операции как: создание, удаление, включение, отключение и обновление. Работа с видами тесно связана с таким мощным инструментом, как ClearCase Details, в чьи обязанности входит постановка/выведение файлов под контроль, получение справочной информации о конкретном элементе, вывод дерева версий… То есть, исходя из названия, данный модуль отвечает за все детали, относящиеся к контролю данных. Соответственно, разработчик большую часть времени будет проводить в работе с ClearCase Details. На рисунке 3 отражено состояние окна ClearCase Home Base, в котором активна вкладка Views. Здесь отображено 5 операций над видами:
ОболочкаНачнем с создания 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 отображено окно выбора, где и производятся все описанные манипуляции. При внимательном рассмотрении представленного списка можно и нужно рассмотреть следующие особенности:
Результатом манипуляций будет создание директории по указанному пути (на втором шаге создания). Все элементы, выбранные для контроля, автоматически скопируются в эту директорию в соответствии с древовидной структурой. Следует учесть особенность Snapshot: никакой виртуальной файловой системы для данного вида ClearCase строить не будет - все будет размещено локально. Создание видов из командной строки Как и при создании репозиториев, ClearCase позволяет создавать новые виды из командной строки (апплет cleartool). Для создания View существует команда "mkview", в чьи обязанности входит создание видов. Данная команда применяется как для создания Snapshot, так и для Dynamic видов. В зависимости от заданной спецификации будет создан необходимый тип вида со всеми переданными ему характеристиками. Создавать виды из командной строки сложнее чем репозитории, особенно это касается создания Snapshot View, в котором необходимо вручную править Config Spec (конфигурационную спецификацию). Перед созданием вида рассмотрим семантику команды MKVIEW: Для динамических видов: mkview -tag view-tag [-tcomment tag-comment] [-tmode text-mode] Для снапшотов: mkview -tag view-tag -snapshot [-vws view-storage-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). Рассмотрим все основные возможности видов:
К сожалению, подробное описание функциональности любого программного обеспечения, а продукта ClearCase особенно, выходит за рамки статьи. Мы не сможем подробно остановиться на создании видов, поскольку это непочатый край работы. Весь материал, изложенный на данных страницах, носит ознакомительно-показательный характер и направлен на популяризацию продукта Rational ClearCase. Соответственно, за рамками данной статьи осталась параллельная разработка на основе профилей и проектные VOB'ы. Я надеюсь устранить данный недостаток в последующих статьях, если хватит времени и сил… Часть 3. Контроль над даннымиПосле создания всех репозиториев и видов настало время попробовать установить файл под контроль программы ClearCase. Как отмечалось ранее, ClearCase в плане контролирования данных способен не только на простой файловый контроль, когда отслеживается изменение одного конкретного файла, но и так называемый контроль за средой, при котором программа начинает контролировать состояние директорий и групп файлов, что помогает разобраться с тем, кто, когда и какой файл внес в проект. Данный аспект можно и нужно отметить как особо важный и сказать, что ClearCase действительно справляется с поставленной задачей. Итак, каким образом можно ставить файлы под контроль? Все необходимые для этого файлы могут быть скопированы в построенные виды и уже в них поставлены под контроль. Существуют всего три операции, проводимые над данными: Постановка под контроль (Add To Source Control). Данная операция является первичной. Основная ее нагрузка - декларация того, что тот или иной файл будет взят под контроль и не более того. Check-in. Поставить под контроль. На этот раз - зарегистрировать файл и вывести ему в древовидной структуре место. Данная операция является стандартной для любых действий, связанных с контролем данных. После задания файлу подобной команды ClearCase в репозитории создаст (закроет) версию файла, которую уже нельзя отредактировать, поскольку он автоматом получает атрибут "read only". Check-out. Не менее стандартная команда, выводящая за рамки контроля файл с целью создания новой версии. После введения данной команды на дереве появляется новое отделение без присвоенного номера, как бы показывающее, что файл уже подлежит изменениям. Ответвление получит новую цифру версии сразу же после активации Check-in для конкретного файла. Что же дает обыкновенному разработчику ClearCase в плане контроля изменений:
К сожалению, все операции со слиянием и сравнением доступны только для известных форматов файлов, в которые, естественно, не входят исполняемые, объектные, графические… - естественно, файлы данного типа можно ставить под контроль и хранить вер-сии, но они будут, подобно амебе, существовать без возможности аналитического анализа. 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. Анализ выведенной информации можно описать так:
Итак, незаметно мы и подобрались к самому интересному - к параллельной разработке. На данном дереве были созданы два ответвления (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. Как видите, все изменения, внесенные нами, отразились на дереве версий достаточно отчетливо:
Командная строка
По традиции рассмотрим выполнение описанных функций из командной строки, а для начала научимся ставить файлы и директории под контроль. Для этого необходимо командой "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, - подобная запись гораздо проще воспринимается и запоминается.
Производить слияния версий можно и из командной строки, правда, контролировать результат проще графически, но… Создание объединения из командной строки сводится к выведению конкретной версии файла (реципиента) в состояние check-out, после чего командой "merge" указывается его имя и путь к тому элементу, из которого будут браться данные для объединения (донора). В нашем случае можно вывести любую версию в состояние check-out, после чего выбрать исходный элемент и запустить все на исполнение.
Результатом работы команды будет создание объединение двух версий файла с разных ветвей. При подобном объединении ClearCase различает два типа объединений: тривиальные и нетривиальные. В случае с тривиальными, то есть с теми, которые можно просто объединить, не задавая вопросы пользователю (например, в новой версии к файлу добавлены две новые строки, естественно при подобном слиянии вопросов задано не будет и слияние произойдет достаточно быстро). С точностью до наоборот обстоит с нетривиальными сравнениями, когда два объединяемых элемента содержат большие расхождения, что приводит к возникновению большого количества вопросов, на которые ClearCase сам не ответит, возложив всю рутину по слиянию на плечи пользователя.
Дополнительные возможности ClearCaseMultiSiteКак известно: аппетит приходит во время еды, стало быть то, что не вызывало интереса до начала описания, должно вызвать его в процессе чтения, на худой конец после него! В предыдущих частях, мы рассмотрели все основные возможности работы программы ClearCase, коснувшись понемногу всех главных аспектов его использования. Естественно, не идет и речи о каком бы то ни было приемлемом по полноте описании данной программы, так как для полного описания потребуется не статья, а учебник, и даже не один. Ведь по большому счету, цель данной статьи - ознакомление конечного пользователя с возможностями продукта: введение в предметную область, общее описание возможностей… и так далее. Начиная с данной главы, мы попытаемся описать некоторые возможности пакета ClearCase, которые являются весьма и весьма интересными и познавательными, но могут и не использоваться в повседневной жизни конкретным разработчиком. Как известно, интерес к продукту во многом зависит не только от его прямых возможностей, но и от того окружения, которое способствует его нормальному функционированию. Скажем, графический интерфейс пришел на смену командной строке, что способствовало, в свою очередь, интересу со стороны пользователей к вычислительной технике. Так получается и в данном случае: ClearCase в чистом виде - это система контроля версий и конфигураций, причем очень хорошая, но… Разработчик пред началом ее использования должен знать - совместно с чем она способна работать, какие у нее сервисные функции и пр. Повторюсь еще раз: идеальное исполнение прямых обязанностей, возложенных на продукт, не есть самое главное. Ниже мы опишем возможность ClearCase, помогающую вести работу над проектом группам разработчиков, чьи офисы находятся на значительном удалении друг от друга (в другом районе, городе, стране, планете…). MultiSite - специальный модуль, дополнительно входящий состав ClearCase и позволяющий обмениваться данными нескольким (двум и более) командам разработчиков. Данный модуль неявно присутствует в любой поставке ClearCase за исключением Attache, и начинает свою работу только после введения специального ключа, дающего "добро" на все возможности репликации проектов. К сожалению, выявить присутствие данного модуля весьма проблематично, поскольку он не имеет графического интерфейса и практически никак не указывает на свое присутствие в системе. Отчасти такое поведение можно считать недостатком, но при детальном углублении в суть проблемы выясняется, что явное отсутствие модуля не такая большая проблема, в силу тех функциональных обязанностей, которые возложены на MultiSite. Основным и единственным предназначением данного модуля является генерация и отправка синхронизационных пакетов - реплик, по указанным IP адресам. Согласитесь, данная функция абсолютно не нужна большинству участников проекта. Подобная идеология и легла в основу "невидимости" модуля: с глаз долой, из сердца вон! И по сложившейся традиции давайте на конкретных примерах разберем функциональные возможности MultiSite, но для начала опишем основные возможности и особенности программы:
Настройка модуля MultiSite производится из единствнного графического аппета, имеющегося в его распоряжении. Местоположение данного модуля столь же неявно, как и само присутствие MultiSite. Апплет находится в ControlPanel и представляет собой настроечное окно. Рисунок 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 и как в принципе создается и передается реплика. Схему передачи можно выразить следующим образом:
Прелесть MultiSite при синхронизации реплик заключается в том, что если за время, прошедшее с момента передачи предыдущей реплики, VOB никак не был изменен, то и реплика не будет создаваться и пересылаться, поднимая до поднебесья трафик компании. Отдельно хочется поговорить о передаче прав на изменение (команда "chmaster"), что позволит не только реплицировать копию VOB, но и передать права на ее правку. Права можно передать как на один элемент, так и на целую группу. Во избежание путаницы, связанной с тем кто, когда, и для кого создавал реплику, MultiSite предоставляет полную статистическую выкладку по синхронизациям для каждого конкретного VOB, при помощи команды "lsreplica". Как видите, MultiSite продукт весьма нужный и весьма важный в тех случаях, когда необходимо связать в один проект удаленные группы разработчиков, которые смогут, пользуясь всеми преимуществами программы ClearCase и не выходя из офиса, создавать и контролировать разрабатываемое программное обеспечение. Интеграция с Visual StudioКомпания Rational очень тесно сотрудничает с Microsoft в области информационных технологий, посему все программные продукты от Rational тем или иным образом интегрируются в первую очередь со средами разработки от MS.
Соответственно, тесная интеграция поддерживается для Visual C++ и Visual Basic. Пользователь, находящийся в данных средах, получает полный набор средств для версионного контроля, не выходя из среды разработки. В принципе, любой программист может разрабатывать что угодно в любой среде, но все операции по контролю производить из ClearCase Detail, контролируя самостоятельно все состояния для каждого отдельного элемента. При "правильно" установленном Visual Studio, возможна работа утилиты сборки из состава ClearCase. Под "правильной" установкой подразумевается подключение Интеграция с VS состоит в появлении ряда функций в подпункте Source Control меню Project, и позволяющий осуществлять обращения к ClearCase не напрямую, а через данный пункт (см. рисунок 14). Как видно из содержимого окна, подобная интеграция подразумевает использование наиболее употребительных функций, ежедневно необходимых для полноценной работы членов команды. Интересный пункт, о котором мы ранее не говорили, - "Get Latest Version", позволяющий получить доступ к последней версии. Необходимость использования данного пункта возникает при работе со Snapshot Views, когда есть необходимость обновлять (синхронизировать), при использовании же динамических видов необходимость в этом пункте отпадает, да и ClearCase, не позволит воспользоваться командой. Естественно, что когда речь заходит о работе с определенным продуктом, то на первое место выходит методология работы с ним: описание механизмов взаимодействия, последовательность действий, и так далее. Интегрировав таким образом две программы встает вопрос: а как дальше работать? Решение может быть следующего вида и характера:
Вот, вкратце описание возможной работы с использованием двух достаточно мощных программных продуктов. Хотя никакие методологии не позволят эффективно работать, если их не придерживаться. ClearCase имеет в своем арсенале такой мощный механизм, как сборщик проектов, позволяющий компилировать и собирать проекты. Утилита, помогающая в данной работе носит название "omake"
. Ее основная задача - сборка проекта на основе 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.
Попробуем в режиме наглядной агитации рассмотреть возможности SoDA, годящиеся для использования совместно с ClearCase, для чего создаем новый репозиторий, виды, вносим некоторое количество файлов. Для создания шаблона вызовем приложение "SoDA getting Started". Поскольку сама сода - продукт встраиваемый в Word и неспособный функционировать отдельно, то SoDA автоматически вызовет сам Word, и ссылку на себя поместит в верхнее меню. Результатом выполненых действий будет появление диалога с предложением выбора типа шаблона, который предстоит генерировать. На рисунке 16 показан внешний вид окна с подобным запросом. В случае с ClearCase доступны следующие виды заранее составленных шаблонов, каждый из которых составляет специфический отчет: Activity
По своим возможностям сода, конечно же, не самый насыщенный инструмент в линейке продуктов 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Поддерживаемые платформы Поддерживаемые файловые системы Unified Change Management Данная реализация поддерживает модель out-of-the-box, включающая мощный набор инструментов для управления и конфигурирования среды разработчика. Для менеджеров проекта и интеграторов, UCM автоматически осуществляет политику разработчика. Добавлены новые команды и интерфейс для UCM ClearCase WEB Interface Как говорилось выше, в новой версии стало возможно получать доступ к проектным файлам через WEB страницы. Данный способ позволяет подключаться как к Dynamic View, так и к Snapshot View. Новые типы файлов и программ, поддерживаемых ClearCase Переработана консоль администратора 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? Вопрос: Что нужно для того, чтобы заработал MultiSite? Вопрос: Можно ли передавать при помощи MultiSite данные не через интернет? Вопрос: Что такое VOB. Его особенности ? Вопрос: Что такое View? Вопрос: Какие типы файлов можно ставить под контроль ClearCase? Вопрос: Обязательно ли при использовании MultiSite обмениваться полными репликами Vob? Вопрос: Совместимы ли PVCS и CleraCase? Вопрос: Существует ли какой ни будь встроенный способ шифрования данных при передаче их при помощи MultiSite? Вопрос: Можно ли осуществлять (и при помощи чего) документирование содержимого проекта? Вопрос: На каких платформах реализован ClearCase? Вопрос: Какие WEB сервера поддерживаются модулем MultiSite?
|