(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

Работа с командной строкой Rational ClearCase. Создание проекта в UCM

Костиков А.В.

Введение

Хочу начать эту статью словами в защиту командной строки ClearCase (утилита cleartool). Вспомним происхождение ClearCase - компания Rational Software взялась за доработку бесплатного Unix-приложения для ведения версионного контроля, несколько лет назад адаптировав своё творение под операционные системы Microsoft. Кому придёт в голову сомневаться в максимальных функциональных возможностях продукта при управлении им из командной строки, если графический интерфейс ClearCase был дописан для пользователей операционных систем семейства Windows?

Но можно привести и другие аргументы при рассуждениях на эту тему...

Много новшеств в рассматриваемой программе появляется в последнее время - когда она с успехом распространяется среди пользователей Windows. Разумно полагать, что основные, наиболее часто исользуемые (и уж тем более появившиеся в последних версиях) возможности ClearCase полнофункционально представлены в GUI (graphical user interface), что и доказывает практика работы с продуктом.

Напрашивается очевидный вывод - каждому своё. Пользователям, которые привыкли работать, набирая команды руками, - полная свобода в ClearCase - будь то администрирование, или повседневная работа разработчика. Тем же, кто уютнее чувствует себя, нажимая кнопки в GUI, не стоит пугаться перспектив перехода в чёрный экран командной строки, потому что большинство задач разработчика рещается из GUI ClearCase, что касается работы администратора - то гарантировать использования 100% возможностей продукта из GUI нельзя.

В статье был рассмотрен процес создания простейшего проекта UCM из GUI. Здесь же, попытаюсь рассказать о создании подобного проекта при помощи команд утилиты cleartool, полагая, что читатель знаком с базовыми понятиями как Rational ClearCase, так и с Rational UCM.

Создание проекта

Как обычно, создание проекта в ClearCase начинается с создания репозиториев (VOB) - проектного (PVOB) и компонентного. Чтобы назначить компонентному репозиторию административным - PVOB, необходимо связать их гиперссылкой типа AdminVOB. И только после этого назначить созданный компонентный VOB компонентой для проектного VOB'а. А теперь приступим непосредственно к командам. Для набора команд необходимо запустить утилиту cleartool - либо из командной строки любого файлового менеджера (команда cleartool), либо непосредственно запустив файл

"~Home_dir_ClearCase~\ClearCase\bin\cleartool.exe".

Не привожу полного описания команд, потому что весь набор ключей можно посмотреть в help. Например, для команды mkvob это делается следующим образом:

Usage: mkvob -tag vob-tag [-ucmproject]
[-c comment / -cfile pname / -cq / -cqe / -nc]
[-tcomment tag-comment]
[-region network-region] [-options mount-options]
[-public] [-password tag-registry-password]
{ [-host hostname -hpath host-stg-pname -gpath global-stg-pname]
vob-storage-pname
/ -stgloc {vob-stgloc-name / -auto}
}

Более подробное описание команды с примерами использования можно получить из ClearCase Help с помощью команды:

cleartool> man mkvob

При помощи именно этой команды создаём репозитории. Для создания проектного VOB'а используется ключ "-ucmproject":

cleartool> mkvob -tag \pvob1 -ucmproject -c "demo" -region Windows \\sash\stg\vobs\pvob1.vbs
cleartool> mkvob -tag \vob1 -c "demo" -region Windows \\sash\stg\vobs\vob1.vbs

Таким образом, созданы проектный и компонентный репозитории \pvob1 и \vob1.

Назначим административным \pvob1 для компонентного \vob1. Это делается командой mkhlink, предварительно перейдя в директорию репозитория \vob1:

cleartool> cd \\sash\stg\vobs\vob1.vbs
cleartool> mkhlink AdminVOB vob:\vob1 vob:\pvob1

Теперь проектному VOB'у надо сообщить, что у него есть компонент. Делается это с помощью команды mkcomp, но для её применения необходим динамический вид, из командной строки которого набирается данная команда. Итак:

cleartool> mkview -tag temp_view -region Windows \\sash\stg\views\temp_view.vws
cleartool> cd M:\temp_view
cleartool> mkcomp -c "demo" -root M:\temp_view\vob1 vob1@\pvob1

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

cleartool> mkproject -c "demo" -modcomp vob1@\pvob1 -in RootFolder@\pvob1 demo_project@\pvob1

Разберём ключи данной команды. Для включения в проект изменяемых компонентов после ключа "-modcomp" необходимо указать их идентификаторы (component-selector) - в рассматриваемом примере указываем созданный ранее компонентный VOB. Данные проекта будут храниться в директории на диске MVFS, - именно эту директорию указываем в ключе "-in". Директория "RootFolder@\any_vob" существует с момента создания репозитория \any_vob. И в одной директории можно создавать несколько проектов. Если же возникла необходимость, то можно создать новую директорию в проектном VOB'е при помощи команды mkfolder и там уже создавать проект. Ну и последний аргумент команды mkproject - имя нового проекта - обычный идентификатор объектов ClearCase ("имя_проекта@идентификатор_проектного_VOB").

Следующий необходимый этап - создание потока слияний (integration stream) в данном проекте. Любой поток (и поток разработчика, и поток слияний) создаётся командой mkstream, но для потока слияний используется ключ "-int":

cleartool> mkstream -int -in demo_project@\pvob1 -baseline vob1_INITIAL@\pvob1 int_str@\pvob1

За ключом "-in" указывается проект, в котором создаётся поток. Что касается базовых линий, то после создания компонента проектного VOB'а в нём генерируется начальная базовая линия с именем имя_компонента_INITIAL, и за ключом "-baseline" можно указать её идентификатор - "имя_компонента_INITIAL@идентификатор_проектного_VOB", если не имеется ранее созданных базовых линий. Просмотреть имеющиеся базовые линии в компоненте можно при помощи команды:

cleartool> lsbl -long -component имя_компонента@идентификатор_проектного_VOB

Теперь пришло время создавать такой базовый объект ClearCase, как вид (view). Причём, в данном цикле статей все примеры приводятся только для динамических видов. Это связано с их функциональными преимуществами над Snapshot View в рамках UCM. Используем команду mkview:

cleartool> mkview -tag int_view -region Windows -stream int_str@\pvob1 \\sash\stg\views\int_view.vws

Здесь стоит сказать лишь о ключе "-stream" - параметр, указывающий на поток, к которому прикрепляется создаваемый вид.

Для того чтобы начать манипулировать данными в репозитории, кроме вида в UCM, необходимо создать и установить в данном виде действие (activity), в рамках которого будут совершаться "checkout" и "checkin" (набор изменений для действия) над элементами VOB'а. Создаётся действие командой mkactivity:

cleartool> mkactivity -c "demo" -in int_str@\pvob1 -nset act_int@\pvob1

За ключом "-in" указывается поток, для которого создаётся действие, если не применить ключ "-nset" то действие после создания будет установлено в виде, привязанном к указанному потоку. В данном случае данный ключприменяется лишь для демонстрации другой команды setactivity:

cleartool> setactivity -c "demo" -view int_view act_int@\pvob1

Ключи данной команды очеидны - действие устанавливается в виде, указанном после ключа "-view" , последний аргумент - идентификатор устанавливаемого действия.

Из вида интегратора (int_view в данном примере) возьмём на редактирование компонентный VOB, с целью создать в нём директорию, в которую затем поместим файл, и поставим его под контроль ClearCase.

cleartool> cd M:\int_view
cleartool> checkout -c "demo" M:\int_view\vob1
cleartool> mkdir -nco -c "demo" M:\int_view\vob1\files
cleartool> checkin -c "demo" M:\int_view\vob1

Стоит пояснить применение команды mkdir. Директорию создавать на диске MVFS подобным образом предпочтительнее потому, что если воспользоватся средствами операционной системы, то получаем скрытый объект данного вида (view-private). И такой объект для занесения в VOB для совместного использования необходимо конвертировать в элемент ClearCase типа директория (directory element). Но зачем делать несколько действий, когда есть возможность использовать всего лишь одну команду mkdir? В данном примере ключ "-nco" использовался лишь для демонстрации его существования. При его использовании, директория (M:\int_view\vob1\files) после создания не ставится в состояние редактирования (checkout). Следующие действия очевидны - выводим директорию в состояние редактирования, копируем в неё необходимый файл с помощью операционной системы. После этого, как говорилось выше, данный, скрытый от других видов файл (view-private), необходимо поставить под контроль (создать элемент соответствующего типа). Я рассмотрю простейший пример - работа с текстовым файлом, формат которого является стандартным для ClearCase.

cleartool> checkout -c "demo" M:\int_view\vob1\files
cleartool> cd M:\int_view\vob1\files
(после исполнения команды копируем в эту директорию файл demo_file.txt)
cleartool> mkelem -nco -c "demo" demo_file.txt
cleartool> checkout -c "demo" M:\int_view\vob1\files\demo_file.txt
(делаем необходимые изменения, и снимаем с редактирования)
cleartool> checkin -c "demo" -identical M:\int_view\vob1\files\demo_file.txt

Ключ "-identical" используется в том случае, если файл после выведения его на редактирование не был изменен, и Вы пытаетесь вернуть его в VOB (checkin). Если ключ не указан, то произойдёт ошибка, и файл не будет снят с редактирования.

cleartool> checkin -c "demo" M:\int_view\vob1\files

Будем считать, что все основные действия с файлом сделаны. Тогда необходимо создать новую базовую линию, и назначить её рекомендованной для конкретного потока (у нас он пока один - поток слияний).

cleartool> mkbl -c "demo" -view int_view -activities act_int@\pvob1 -full new_bl
cleartool> chstream -c "demo" -recommended new_bl int_str@\pvob1

Здесь командой "mkbl" создаём новую базовую линию в виде "int_view" (по ключу "-view"), соствляя её из всех элементов компонента (ключ "-full"), изменённых действием "act_int@\pvob1" (по ключу "-activity"). Чтобы изменить какие-либо свойства потока - политку потока (stream policies), поток сдачи действий по умолчанию и рекомендованную базовую линию - используется команда "chstream". В данном случае надо было изменить всего лишь рекомендованную базовую линию. Как приведено выше, для этого используется ключ "-recommended" и имя базовой линии потока "new_bl". Имя изменяемого потока указывается последним параметром команды ("int_str@\pvob1").

В раках рассматриваемого примера, интегратор (или менеджер проекта) переходит на следующий этап работ - создание и конфигурирование потока и вида разработчика.

Создание потока и вида разработчика.

О командах создания вида и потока было сказано в начале статьи. Отличается использование "mkstream" только отсутствием ключа "-int", что очевидно.

cleartool> mkstream -in demo_project@\pvob1 -c "demo" -baseline new_bl dev_str@\pvob1
cleartool> mkview -tag dev_view -stream dev_str@\pvob1 \\sash\stg\views\dev_view.vws

При создании потока назначаем ему базовую линию: "-baseline new_bl". Вид разработчка с тэгом "dev_view" прикрепляется к только что созданному потоку "dev_str@\pvob1"с помощью ключа "-stream". Здесь я не использовал ключ "-region", потому что регион (region) по умолчанию совпадает с хостом, на котором выполняется команда создания вида ("mkview"). Убедиться в правильности действий можно следующим образом:

cleartool> cd M:\dev_view\vob1\files
cleartool> ls
demo_file.txt@@\main\int_str\1

Rule: new_bl -mkbranch dev_str

Как видим, создан вид, а точнее диск MVFS - "M:\dev_view", наполненный необходимыми версиями файлов (версия файла demo_file.txt).

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

cleartool> mkactivity -c "demo" -in dev_str@\pvob1 -nset dev_act@\pvob1
cleartool> setactivity -c "demo" -view dev_view dev_act@\pvob1
cleartool> checkout -c "demo" M:\dev_view\vob1\files\demo_file.txt
(редактирование файла demo_file.txt)
cleartool> checkin -c "demo" -identical M:\dev_view\vob1\files\demo_file.txt

Замечу, что взятие-возврат файла на редактирование и правка его может проводиться многократно в пределах одного действия, хотя по концепции UCM рекомендуется, всё же, создавать лишь одну новую версию файла в действии.

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

cleartool> deliver -stream dev_str@\pvob1 -to int_view -activities dev_act -force
Changes to be DELIVERED to default target stream in project "demo_project":
FROM: stream "dev_str"
TO: stream "int_str"
Using target view: "int_view".
Needs Merge "M:\int_view\vob1\files\demo_file.txt" [(automatic) to \main\int_str\1 from \main\int_str\dev_str\2 (base also \main\int_str\1)]
Checked out "M:\int_view\vob1\files\demo_file.txt" from version "\main\int_str\1".
Attached activities:
activity:deliver.dev_str.20020320.005753@\pvob1 "deliver dev_str on 20.03.2002 0:57:53."
Needs Merge "M:\int_view\vob1\files\demo_file.txt" [to \main\int_str\CHECKEDOUT from \main\int_str\dev_str\2 base \main\int_str\1]
Trivial merge: "M:\int_view\vob1\files\demo_file.txt" is same as base "M:\int_view\vob1\files\demo_file.txt@@\main\int_str\1".
Copying "M:\int_view\vob1\files\demo_file.txt@@\main\int_str\dev_str\2" to output file.
Moved contributor "M:\int_view\vob1\files\demo_file.txt" to "M:\int_view\vob1\files\demo_file.txt.contrib".
Output of merge is in "M:\int_view\vob1\files\demo_file.txt".
Recorded merge of "M:\int_view\vob1\files\demo_file.txt".
Deliver has completed
FROM: stream "dev_str"
TO: stream "int_str"
Using target view: "int_view".

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

"-stream" - указываем поток, из которго происходит сдача действия (dev_str@\pvob1);
"-to" - вид, прикреплённый к потоку слияний ("int_view");
"-activities" - перечень сдаваемых действий ("dev_act");
"-force" - ClearCase исключает участие пользователя в сдаче действия, естесственно, и процесс слияния (merge) происходит автоматически.

После удачного выполнения этой команды в потоке слияний появляется действие с набором изменений, внесённых сдачей действий разработчика. В данном примере сгенерированный заголовок действия - deliver dev_str on 20.03.2002 0:57:53.

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

cleartool> rebase -view dev_view -baseline bl_after_test
Advancing to baseline "bl_after_test" of component "vob1"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Needs Merge "M:\dev_view\vob1\files\demo_file.txt" [(automatic) to \main\int_str\dev_str\2 from \main\int_str\3 (base also \main\int_str\dev_str\2)]
Checked out "M:\dev_view\vob1\files\demo_file.txt" from version "\main\int_str\dev_str\2".
Attached activities:
activity:rebase.dev_str.20020320.035545@\pvob1 "rebase dev_str on 20.03.2002 3:55:45."
Needs Merge "M:\dev_view\vob1\files\demo_file.txt" [to \main\int_str\dev_str\CHECKEDOUT from \main\int_str\3 base \main\int_str\dev_str\2]
Trivial merge: "M:\dev_view\vob1\files\demo_file.txt" is same as base "M:\dev_view\vob1\files\demo_file.txt@@\main\int_str\dev_str\2".
Copying "M:\dev_view\vob1\files\demo_file.txt@@\main\int_str\3" to output file.
Moved contributor "M:\dev_view\vob1\files\demo_file.txt" to "M:\dev_view\vob1\files\demo_file.txt.contrib".
Output of merge is in "M:\dev_view\vob1\files\demo_file.txt".
Recorded merge of "M:\dev_view\vob1\files\demo_file.txt".
Build and test are necessary to ensure that the merges were completed correctly.

When build and test are confirmed, run "cleartool rebase -complete".
cleartool> rebase -complete
Rebase in progress on stream "dev_str".
Started by "Sasha" at 20.03.2002 3:55:45.
Merging files...
Checking in files...
Clearing integration activity...
Updating stream's configuration...
Cleaning up...
Rebase completed.

В данном примере синхронизация происходила в два этапа - сначала были обновлены версии файлов, создано действие слияния и файлы взяты на редактирование в виде разработчика. После этого разработчику даётся возможность убедиться в корректности автоматического слияния версий (синхронизация прервана - файлы находятся в состоянии "checkout"). Если разработчик убеждается в корректности слияния, то второй этап - продолжение синхронизации (команда "rebase -resume"). Тем самым синхронизация завершена, и вид разработчика наполнен версиями файлов базовой линии, указанной в команде "rebase" за ключом "-baseline" ("bl_after_test"). Опять же, как и в случае с командой "deliver", выведенный на экран текст - информация о действиях ClearCase, где можно легко отследить какие версии файлов были слиты (merge) автоматически.

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

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



 Распечатать »
 Правила публикации »
  Обсудить материал в конференции IBM Rational/Telelogic - системный инжиниринг, управление требованиями, изменениями, жизненным циклом ИС, умное управление проектами »
Написать редактору 
 Рекомендовать » Дата публикации: 26.03.2002 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Rational ClearCase Multisite Floating User License
IBM Rational Functional Tester Floating User License
IBM Rational Method Composer Authorized User License
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
Rational ClearQuest Floating User License
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Программирование на Visual Basic/Visual Studio и ASP/ASP.NET
Каждый день новые драйверы для вашего компьютера!
3D и виртуальная реальность. Все о Macromedia Flash MX.
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
Обсуждения в форумах
Access, Ключевое поле, Счетчик (10)
Подскажите пожалуйста, как изменить в Access в ключевом поле (счетчик последовательно),...
 
Решение задач на оптимизацию с помощью MS Excel (4)
Zdravstvuyte, ya pro4itala danniy material, no ne smogla ponat kakie formuli ispolzovalis v...
 
Отличается ли ДрифтКазино от беттинга? (4)
Друзья, давно заметил, что на Дрифте уже несколько месяцев во всю рекламируется и предлагается...
 
Где взять лицензионный ключ для AllFusion Process Modeler (BPwin) 7? (5)
Выручайте!!! где найти ключ, ужасно срочно нужна программа. заранее спасибо!
 
работа на дому! (5)
Доброго времени суток дорогие друзья. Многоуровневый маркетинг окончательно признан...
 
 
 



    
rambler's top100 Rambler's Top100