Особенности создания видов
Итак, если вспомнить базовые возможности ClearCase в области хранения информации, то получается, что мы должны создать репозитарий (VOB), создать вид (один или несколько), затем любым известным способом копировать/сохранять файлы и директории на диск, созданный ClearCase, и установить за ними контроль (рис. 9).
Рис. 9. Здесь показан вид файла Alex.cpp, выведенного в состояние Check-Out. Скриншот сделан из текущего вида.
Здесь кроется определенная проблема: как организовать при этом совместный доступ к одному файлу и как будут поддерживаться разные версии и разные проекты? Это не праздные вопросы! Давайте посмотрим, что имеется в арсенале ClearCase для решения данных проблем. Но прежде хочу еще раз напомнить очень важный момент: ClearCase имеет свою особенную идеологию работы, которая не всегда понятна с первого взгляда, поскольку требует некоторого осмысления. Поэтому следует воздержаться от попыток "подмять" его под свои нужды. Скорее всего, это не получится, так как для получения наибольшей эффективности проще будет перестроить существующий подход - на тот, что предлагает ClearCase.
По умолчанию ClearCase создает простой вид и назначает ему букву (если это касается динамических видов). При этом если в проекте несколько участников, работающих в локальной сети, то каждый из них, создав подобный вид, будет "смотреть" на одну и ту же часть проекта, как если бы все имели один сетевой диск (рис. 10).
Рис. 10. Здесь показан вид файла , с другого компьютера.
Следует иметь в виду, что ClearCase имеет особую файловую систему - MVFS (MultiVersion File System), которая позволяет получать доступ к версии конкретного файла и производить его правку. Здесь необходимо учитывать, что при простом обращении к нужному файлу ClearCase предоставляет последнюю версию либо версию, находящуюся в состоянии Check-out (для разработчика, который взял файл на редактирование, ClearCase будет подставлять версию Check-out, для всех остальных участников - последнюю; рис. 9, рис. 10, рис. 11 и рис. 12 соответственно).
Рис 11.
Так выглядит дерево версий для файла в текущем виде.
Такое положение приводит к тому, что каждый разработчик может взять один и тот же файл и заняться его доработкой: Но правильно ли это? Ответ - НЕТ. Это неверно, поскольку после того, как разработчики закончат правку файла и дадут команду Check-in, ClearCase не сможет просто создать новую версию - ему придется вызвать MergeManager для объединения новой версии с существующей. А ведь разработчику следует как можно реже прибегать к данному модулю, чтобы не усложнять и без того непростую разработку программного обеспечения. Правда, выход есть и из такой ситуации. Когда пользователь выводит файл в состояние редактирования (Check-out), ClearCase выводит окно, в котором просит ввести комментарий для события, а также то, каким образом файл будет представляться далее в проекте: RESERVED или UNRESERVED. Состояние RESERVED превращает версию в зарезервированную за конкретным владельцем, и ClearCase не позволит другому пользователю сделать новую. Состояние UNRESERVED позволяет всем участникам проекта создавать свои подверсии файла, но при этом самый "шустрый" пользователь, нажавший кнопку Check-in первым, устанавливает контроль за файлом как обычно, а остальным придется производить слияниe с новой версией (рис. 13).
Так происходит подстановка в виде файла с нужной версией в качестве файла по умолчанию. Необходимость правки данного правила появляется, когда команде разработчиков требуется воспользоваться главным преимуществом ClearCase - параллельной разработкой, при которой каждый участник может создать свое ответвление на дереве версий и дорабатывать файл независимо от состояния проекта, чтобы в итоге объединить свою версию с основной. Менеджеру проекта также доступны преимущества параллельной разработки: во-первых, можно вести одновременно две версии различающихся файлов - с целью дальнейшего включения в другой проект, а во-вторых, по технологии Rational, решение о том, какие файлы с какими объединять, в итоге принимает не разработчик, а именно менеджер проекта. В ClearCase есть две возможности изменения существующих правил: ручная правка (при этом требуется знание синтаксиса правил), автоматическая правка (построение профилей и видов на их основе либо ассоциация видов с соответствующими профилями). Рассмотрим сначала построение видов на базе профилей. Профили можно создавать сразу после инсталляции ClearCase в отдельно отведенный каталог, открытый для общего доступа. Здесь кроется основная проблема начинающих пользователей! ClearCase сам не создает каталоги и не настраивает свой доступ к ним - это приходится делать вручную. Путь к созданному каталогу (абсолютно пустому) прописывается на вкладке "Администрирование", как показано на рис. 14.
В результате операции будет создан новый вид (новый диск), в котором отсутствуют файлы проекта. Отсутствие это временное, поскольку создание вида по профилю подразумевает слияние одного или нескольких файлов из предыдущего вида в текущий. Иными словами, для параллельной разработки можно брать не весь проект, а только указанные его части (файлы, директории). Разумеется, все изменения будут отражены на дереве версий. Здесь необходимо акцентировать внимание на том, что методом профилей можно организовать не только параллельную разработку, но и разбивку проекта на несколько частей. Например, одна часть проекта - DEVELOPMENT - доступна всем и отображает все версии всех файлов, но с текущей версией только на ветви MAIN, а вторая часть - RELEASE - содержит только те файлы, которые подлежат компиляции. И наконец, DEBUG - часть, содержащая отладочные версии файлов. Все эти ветви можно сделать при помощи профилей либо с помощью ручной правки правил (рис. 16).
Так можно сравнить, а затем и объединить два каталога. Обратите внимание на красную стрелку и синие полосы - это отсутствующий файл, требующий объединения. Здесь необходимо помнить, что каталог также является элементом и ему присваивается новый номер версии каждый раз, когда в состав проекта вносится новый файл или подкаталог.
Нам требуется создать отдельный диск и поместить в него для сборки только работающие версии файлов. На основе правил проблема решается очень быстро! В процессе редактирования файлов каждый разработчик отмечал на дереве версий ту, которая считалась окончательной версией с соответствующим номером "REL1", "REL2", "REL3" и т.д. Для этого в ClearCase предусмотрен еще один механизм - механизм меток - простых, обыкновенных меток, знакомых всем с первых шагов в программировании. Разработчик вместе с менеджером проекта выбирают одну из версий на дереве и присваивают ей имя. В дальнейшем данная метка становится синонимом конкретной версии конкретного файла, то есть одну и ту же метку необходимо назначать разным файлам и разным подверсиям. В итоге мы можем по меткам собрать требующуюся нам окончательную версию (релиз) файла. Отметим, что ClearCase обладает очень хорошим механизмом защиты от удаления меток: удалить метку может только тот, кто ее создал, либо администратор. Подкорректировать вышеприведенное стандартное правило для того, чтобы ClearCase показывал только все версии с меткой , можно так, как это произведено на рис. 19.
