| СТАТЬЯ |
09.07.01
|
ClearCase – система конфигурационного и версионного контроля
Новичков
Александр
технический специалист,
Interface Ltd.
Компьютер-пресс #5 2001
Статья была опубликована на сайте www.compress.ru
Итак, если вспомнить базовые возможности ClearCase в области хранения информации, то получается, что мы должны создать репозитарий (VOB), создать вид (один или несколько), затем любым известным способом копировать/сохранять файлы и директории на диск, созданный ClearCase, и установить за ними контроль.
Рис. 9. Здесь показан вид файла Alex.cpp, выведенного
в состояние Check-Out.
Скриншот сделан из текущего вида
Здесь кроется определенная проблема: как организовать при этом совместный доступ к одному файлу и как будут поддерживаться разные версии и разные проекты? Это не праздные вопросы! Давайте посмотрим, что имеется в арсенале ClearCase для решения данных проблем. Но прежде хочу еще раз напомнить очень важный момент: ClearCase имеет свою особенную идеологию работы, которая не всегда понятна с первого взгляда, поскольку требует некоторого осмысления. Поэтому следует воздержаться от попыток “подмять” его под свои нужды. Скорее всего, это не получится, так как для получения наибольшей эффективности проще будет перестроить существующий подход – на тот, что предлагает ClearCase.
По умолчанию ClearCase создает простой вид и назначает ему букву (если это касается динамических видов). При этом если в проекте несколько участников, работающих в локальной сети, то каждый из них, создав подобный вид, будет “смотреть” на одну и ту же часть проекта, как если бы все имели один сетевой диск
Рис. 10. Здесь показан вид файла «Alex.cpp», с другого компьютера
Следует иметь в виду, что ClearCase имеет особую файловую систему – MVFS (MultiVersion File System), которая позволяет получать доступ к версии конкретного файла и производить его правку. Здесь необходимо учитывать, что при простом обращении к нужному файлу ClearCase предоставляет последнюю версию либо версию, находящуюся в состоянии Check-out (для разработчика, который взял файл на редактирование, ClearCase будет подставлять версию Check-out, для всех остальных участников – последнюю; рис. 9, рис. 10, рис. 11 и рис. 12 соответственно).
|
Рис. 9.
|
Рис. 10.
|
|
Рис. 11. Так выглядит дерево версий для файла
в текущем виде
 |
Рис. 12. Так выглядит дерево версий для файла
в текущем виде
 |
Такое положение приводит к тому, что каждый разработчик может взять один и тот же файл и заняться его доработкой… Но правильно ли это?
Ответ – НЕТ. Это неверно, поскольку после того, как разработчики закончат правку файла и дадут команду Check-in, ClearCase не сможет просто создать новую версию – ему придется вызвать MergeManager для объединения новой версии с уже существующей. А ведь разработчику следует как можно реже прибегать к данному модулю, чтобы не усложнять и без того непростую разработку программного обеспечения. Правда, выход есть и из такой ситуации.
Когда пользователь выводит файл в состояние редактирования (Check-out), ClearCase выводит окно, в котором просит ввести комментарий для события, а также то, каким образом файл будет представляться далее в проекте: RESERVED или UNRESERVED.
Состояние RESERVED превращает версию в зарезервированную за конкретным владельцем, и ClearCase не позволит другому пользователю сделать новую.
Состояние UNRESERVED позволяет всем участникам проекта создавать свои подверсии файла, но при этом самый “шустрый” пользователь, нажавший кнопку Check-in первым, устанавливает контроль за файлом как обычно, а остальным придется производить слияниe с новой версией.
Рис. 13. Так выглядит дерево в случае, если два пользователя
одновременно ввели один и тот же файл в состояние Check-in. Как видим, сделать
это можно, только стоит ли подменять работу одного человека работой другого?
Отсюда вывод: если вы пользуетесь только однотипными видами, то в большинстве случаев лучше пользоваться операцией RESERVED.
Разумеется, ClearCase предлагает и более эффективные способы работы, правда, для их осуществления на практике необходимы некоторые знания.
Каждый вид строится на базе специальных правил (Rules), которые можно найти на вкладке со свойствами вида. Правило по умолчанию отражает лишь то, о чем мы говорили выше, и выглядит следующим образом:
element * CHECKEDOUTЭто значит: показать в виде все элементы в состоянии CHECKEDOUT или LATEST. Так происходит подстановка в виде файла с нужной версией в качестве файла по умолчанию.
Необходимость правки данного правила появляется, когда команде разработчиков требуется воспользоваться главным преимуществом ClearCase – параллельной разработкой, при которой каждый участник может создать свое ответвление на дереве версий и дорабатывать файл независимо от состояния проекта, чтобы в итоге объединить свою версию с основной. Менеджеру проекта также доступны преимущества параллельной разработки: во-первых, можно вести одновременно две версии различающихся файлов – с целью дальнейшего включения в другой проект, а во-вторых, по технологии Rational, решение о том, какие файлы с какими объединять, в итоге принимает не разработчик, а именно менеджер проекта.
В ClearCase есть две возможности изменения существующих правил: ручная правка (при этом требуется знание синтаксиса правил), автоматическая правка (построение профилей и видов на их основе либо ассоциация видов с соответствующими профилями).
Рассмотрим сначала построение видов на базе профилей.
Профили можно создавать сразу после инсталляции ClearCase в отдельно отведенный каталог, открытый для общего доступа. Здесь кроется основная проблема начинающих пользователей! ClearCase сам не создает каталоги и не настраивает свой доступ к ним – это приходится делать вручную. Путь к созданному каталогу (абсолютно пустому) прописывается на вкладке “Администрирование”, как показано на рис. 14.
Рис. 14. Данная вкладка представляет собой часть окна
администрирования
После настройки путей становится полностью доступной вкладка Branches – ClearCase HomeBase.
Рис. 15. Обратите внимание на выделенные пункты. Они
появятся только при указании пути к правильной директории Profiles, в противном
случае пункты могут либо отсутствовать, либо не активироваться
При корректной установке можно смело нажимать на кнопку View Profile и создавать новый видовой профиль. Именовать его можно либо своим именем, либо по версии проекта (в зависимости от конкретной ситуации).
Обязательно следует указать имя VOB, для которого строится вид, а затем наименование ответвления. В результате операции будет создан новый вид (новый диск), в котором отсутствуют файлы проекта. Отсутствие это временное, поскольку создание вида по профилю подразумевает слияние одного или нескольких файлов из предыдущего вида в текущий. Иными словами, для параллельной разработки можно брать не весь проект, а только указанные его части (файлы, директории). Разумеется, все изменения будут отражены на дереве версий.
Здесь необходимо акцентировать внимание на том, что методом профилей можно организовать не только параллельную разработку, но и разбивку проекта на несколько частей. Например, одна часть проекта – DEVELOPMENT – доступна всем и отображает все версии всех файлов, но с текущей версией только на ветви MAIN, а вторая часть – RELEASE – содержит только те файлы, которые подлежат компиляции. И наконец, DEBUG – часть, содержащая отладочные версии файлов. Все эти ветви можно сделать при помощи профилей либо с помощью ручной правки правил.
Рис. 16. Примерно так будет выглядеть дерево версий одного
файла из Dev/View. Как видите, вторая версия файла была взята на доработку в
разные проекты
Все перечисленные возможности позволяют гибко настраивать среду ClearCase. В свою очередь, возможность построения подобных видов позволяет не привязываться строго к одному средству разработки. Таким образом, ClearCase является средой хранения cборки и сопровождения для любых средств разработки.
В предыдущей части мы уже рассматривали модуль ClearCase, именуемый MergeManager, и говорили о том, что данный модуль способен показать разницу в двух файлах и собрать на их основе третий. Этот же модуль используется и для внесения нужных файлов в вид, построенный по профилю. В этом случае пользователь работает с уже привычным окружением, не тратя драгоценного времени на изучение нового материала. Все видовые профили рекомендуется создавать на сервере так, чтобы любой разработчик мог построить вид на базе уже созданного профиля, а сами профили (по технологии Rational) должен создавать либо менеджер проекта, либо заменяющее его лицо (хотя в принципе профили могут создавать и сами разработчики) (рис. 17 и рис. 18).
Рис 17. Так можно сравнить, а затем и объединить два
каталога.
Обратите внимание на красную стрелку и синие полосы — это отсутствующий файл,
требующий объединения. Здесь необходимо помнить, что каталог также является
элементом и ему присваивается новый номер версии каждый раз, когда в состав
проекта вносится новый файл или подкаталог
Рис 18. Данный рисунок демонстрирует дополнительные возможности
по сравнению состава каталогов, взятых из разных версий наборов. Необходимо
напомнить, что ClearCase хранит не только историю редактирования каждого элемента,
но и запоминает состав файлов в проекте. Таким образом, разработчик получает
возможность вернуться на несколько шагов назад с точки зрения состава проекта
Мы рассмотрели самый простой способ создания видов. Если же разработчик (менеджер проекта) способен запомнить некоторые правила создания видов, то новые виды можно строить как угодно, меняя только правила просмотра. Если вид – это фильтр, то правило (Rule) – это своего рада маска для выбора. Не всегда нужно строить новый вид и создавать новый профиль для того, чтобы связать воедино несколько файлов, проще дать команду фильтрации по правилам.
По умолчанию ClearCase работает по правилу:
element * CHECKEDOUTЭто означает, что все файлы находятся в состоянии CHECKEDOUT либо это их последние версии.
Язык правил ClearCase достаточно прост. Как и многие другие операции, задание правил можно осуществлять как из пользовательского интерфейса, так и из командной строки. В последнем случае необходимо ознакомиться с командами “edcs” – редактирование записи для текущего или установленного вида, “catcs” – просмотреть текущее правило в текстовом режиме без возможности редактирования и “setcs” – установить новое правило, причем само правило необходимо оформить в виде отдельного файла, доступного всем участникам проекта, так, чтобы каждый из них мог ассоциировать свой вид с необходимым в данный момент правилом.
К чему такие сложности? Рассмотрим пример. Предположим, что ведется проект из 20 файлов, каждый из которых является исходным текстом и подлежит компиляции, и у каждого файла большая история редактирования. Нам требуется создать отдельный диск и поместить в него для сборки только работающие версии файлов.
На основе правил проблема решается очень быстро! В процессе редактирования файлов каждый разработчик отмечал на дереве версий ту, которая считалась окончательной версией с соответствующим номером “REL1”, “REL2”, “REL3” и т.д. Для этого в ClearCase предусмотрен еще один механизм – механизм меток – простых, обыкновенных меток, знакомых всем с первых шагов в программировании. Разработчик вместе с менеджером проекта выбирают одну из версий на дереве и присваивают ей имя. В дальнейшем данная метка становится синонимом конкретной версии конкретного файла, то есть одну и ту же метку необходимо назначать разным файлам и разным подверсиям.
В итоге мы можем по меткам собрать требующуюся нам окончательную версию (релиз) файла. Отметим, что ClearCase обладает очень хорошим механизмом защиты от удаления меток: удалить метку может только тот, кто ее создал, либо администратор.
Подкорректировать вышеприведенное стандартное правило для того, чтобы ClearCase показывал только все версии с меткой “REL1”, можно так, как это произведено на рис. 19.
Рис. 19. Обратите внимание: первая версия для данного
вида стала текущей, а самой версии назначено две метки (ClearCase позволяет
поставить и больше — для тех случаев, когда одна и та же версия файла переходит
из одного релиза в другой без изменений)
Можно, например, включить в фильтр все файлы с расширением BAT с нулевой версией, тогда правило будет иметь следующий вид:
element * CHECKEDOUTИли можно настроить ClearCase так, чтобы выводились файлы строго определенного типа (в ClearCase, как и в жизни, расширения могут различаться, а типы файлов совпадать, например, архивные файлы). Правило будет выглядеть так:
element * CHECKEDOUTИли просто отсортировать все файлы по дате или/и времени “…\bugfix\LATEST – time yesterday”,
time 10-Jul.19:00И самое главное: ClearCase позволяет создавать архив правил в виде отдельных файлов, которые можно загружать директивой Include.
Таким образом, одну и ту же функцию продукт способен выполнить несколькими способами. И здесь нельзя сказать, что один способ лучше, а другой хуже – все они одинаково полезны. Сам проект только выиграет, если все способы будут применяться одновременно.
Разработчик может создавать различные ответвления версий своих файлов исключительно для собственного удобства, делая ответвления командой mkbranch, менеджер проекта совместно с разработчиком ставит метку с номером сборки проекта на конкретную версию. Если необходимо осуществить редактирование одного файла силами более одного человека, то прибегают к помощи MergeManager и профилей. А для создания сборок пишут правило ConfigSpec (Configuration Specification), по которому будут выводиться файлы.
Требования для клиентской части:
Требования для серверной части:
Поддерживаемые Web-браузеры:
Поддерживаемые Web-cерверы
Поддерживаемые операционные системы
Интеграция со средствами разработки:
ClearCase на сегодняшний день является самой продвинутой системой версионного и конфигурационного управления, снабженной новейшими достижениями в области SCM (Source Code/Configuration Management). Поскольку ClearCase является системой корпоративного уровня, рекомендовать ее можно всем предприятиям, число разработчиков в которых больше пяти. Все мощные возможности этого продукта раскрываются при использовании его на крупных предприятиях с большим количеством разработчиков. ClearCase – поистине незаменимый продукт, когда речь заходит об объединении регионально удаленных команд разработчиков.
Подробности о ClearCase и ознакомительную версию продукта можно найти на Web-сайте компании Rational Software Corporation www.rational.com.
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Отправить
ссылку на страницу по e-mail
Обсудить на форуме Rational Software
| Interface Ltd. Отправить E-Mail http://www.interface.ru |
|
| Ваши
замечания и предложения отправляйте
автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 24.07.01 |