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