Работа с командной строкой 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) автоматически.
Легко видеть, что теперь процесс разработки замыкается в итерационную схему
достижения необходимого уровня качества разрабатываемого продукта.
Чтобы осознать, а точнее, увидеть, - что же было проделано с помощью командной
строки, можно воспользоваться утилитой просмотра дерева версий в графическом
режиме (см. рис.).
Дополнительная информация
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Обсудить на форуме Rational Software
Отправить ссылку на страницу по e-mail