Из AccuRev в Rational Team Concert

Обзор

По существу, системы управления конфигурациями ПО - это базы данных, которые обеспечивают управление версиями сохраненных элементов. Однако из-за различий в функциях и внутренней организации этих баз данных миграция с одной системы управления конфигурациями ПО на другую редко бывает простым процессом.

IBM® Rational Team Concert™ объединяет управление исходным кодом с другими инструментами, такими как управление дефектами и управление требованиями. В этой статье описывается перенос исходного кода из репозитория AccuRev в Rational Team Concert с историей файлов исходного кода и без нее. В данном контексте исходный код - это код программного обеспечения, находящегося в разработке, а не двоичные файлы для AccuRev или Rational Team Concert.

Прежде всего необходимо определить, нужно ли выполнять миграцию истории файлов исходного кода. При большом объеме исходного кода (например, в случае большого депо AccuRev) можно выбрать перенос только исходного кода без истории, показывающей, какие файлы были изменены и какие изменения были сделаны. В этой статье описывается перенос исходного кода из AccuRev в Rational Team Concert с историей файлов исходного кода и без нее.

Схема потоков в AccuRev

Чтобы понять схему потоков в AccuRev, рассмотрим пример разработки продукта ANT. В начале схема продукта в депо AccuRev проста (см. рисунок 1). Файлы ANT 1.0 расположены в потоке Next2Ship_Build. Разработчики создают свои рабочие области вне этого потока. Сборки выполняются из потока Next2Ship_Build.

Рисунок 1. Пример потока для ANT в AccuRev

Пример потока для ANT в AccuRev

Через несколько месяцев версия ANT 1.0 готова к выпуску. Инженер по выпуску создает снимок потока Next2Ship_Build, изображенный на рисунке 2 в виде круга с надписью v1.0_RTM. Затем он создает вне этого снимка новый поток сборки v1.0_Build для поддержки версии ANT 1.0.

В этой точке начинается разработка версии ANT 2.0 в потоке Next2Ship_Build. Через несколько месяцев версия ANT 2.0 готова к выпуску. Инженер по выпуску создает снимок потока Next2Ship_Build, изображенный на рисунке 2 в виде круга с надписью v2.0_RTM. Затем он создает вне этого снимка новый поток сборки v2.0_Build для поддержки версии ANT 2.0.

Рисунок 2. Несколько потоков для ANT в AccuRev

Несколько потоков для ANT в AccuRev

Перенос файлов исходного кода без истории

Примечание. В статье предполагается предварительное создание рабочей области и проекта Rational Team Concert с потоками.

Для переноса файлов в Rational Team Concert без включения истории файлов исходного кода выполните следующие шаги:

С помощью заданного шаблона создайте в Rational Team Concert проект и поток RTC_Stream в этом проекте. Потоки являются контейнерами для компонентов, которые, в свою очередь, являются контейнерами для управляемых версиями артефактов.
Создайте рабочую область вне потока RTC_Stream.
Получите файлы из снимка v1.0_RTM в AccuRev, скопируйте их в рабочую область Rational Team Concert и передайте их в RTC_Stream.
Создайте снимок v1.0_RTM из RTC_Stream.
Получите файлы из снимка v2.0_RTM в AccuRev, скопируйте их в рабочую область Rational Team Concert и передайте их в RTC_Stream.
Вы можете видеть исходящие изменения новых и модифицированных файлов.
Что касается удаленных файлов, необходимо сравнить рабочие области AccuRev и Rational Team Concert, определить файлы, удаленные из рабочей области AccuRev, и удалить их вручную из рабочей области Rational Team Concert. Убедитесь, что исходящие изменения включают все новые и удаленные файлы. После обработки изменений рабочая область Rational Team Concert будет аналогична рабочей области AccuRev. После завершения этого шага снимок v2.0_RTM будет успешно перенесен.
Повторите шаги 5, 6 и 7 для главного потока Next2Ship_Build.
Повторите этот процесс для потоков v1.0_Build и v2.0 Build.
Продолжите процесс для дополнительных потоков.
Сравните рабочие области AccuRev и Rational Team Concert для всех потоков и убедитесь, что они синхронизированы.

После выполнения этих шагов файлы исходного кода будут перенесены из депо AccuRev в область проекта Rational Team Concert. Однако история файлов исходного кода, которая отслеживалась в AccuRev, перенесена не будет. При использовании этого метода история файлов исходного кода теряется.

Оставшаяся часть статьи посвящена переносу файлов исходного кода с сохранением истории.

Перенос файлов исходного кода с историей

Для сохранения истории файлов исходного кода нужно пересоздать депо AccuRev как области проекта Rational Team Concert. Целью является соответствие каждой области проекта депо AccuRev в отношении:

иерархии потоков;
содержимого потоков;
снимков.

При пересоздании депо AccuRev как областей проекта Rational Team Concert история изменений передается из системы AccuRev, результаты текущей разработки не меняются, а права доступа и полномочия сохраняются. Несмотря на то, что такая миграция практически не затрагивает разработчиков, перенести их рабочие области с AccuRev в Rational Team Concert невозможно.

Чтобы выполнить перенос файлов исходного кода с сохранением их истории, используйте схему, показанную на рисунке 3, и следуйте этому потоку работ для создания системы миграции.

Рисунок 3. Блок-схема системы миграции

Блок-схема системы миграции

Система миграции, показанная на рисунке 3, содержит следующие основные компоненты:

Компонент	Описание
Сервер AccuRev	Машина, на которой размещен исходный репозиторий AccuRev.
Исходная клиентская машина	Машина с сетевым доступом к серверу AccuRev.
Клиент AccuRev	Приложение, выполняющееся на исходной клиентской машине. Оно предоставляет пользовательский интерфейс для репозитория AccuRev. Пользователи могут выбирать между графическим интерфейсом и командной строкой.
Исходный агент	Специализированное приложение, выполняющееся на исходной клиентской машине. Оно обеспечивает доступ к AccuRev из командной строки, предоставляемой клиентом AccuRev.
Почтовый ящик	Папка в общей файловой системе, которая используется для передачи пакетов от исходного агента целевому агенту.
Пакет	Структура данных, полностью определяющая любое обновление репозитория AccuRev.
Сервер Jazz	Машина, на которой расположен целевой (Rational Team Concert) репозиторий.
Целевая клиентская машина	Машина с сетевым доступом к серверу Jazz.
Программный интерфейс Rational Team Concert Java API	Набор Java-классов, позволяющий создавать сценарии с использованием операций Rational Team Concert.
Целевой агент	Специализированное приложение, выполняющееся на целевой клиентской машине. Оно обращается к репозиторию Rational Team Concert посредством Rational Team Concert Java API.

Поток работ по переносу депо AccuRev

Чтобы создать систему миграции для переноса депо AccuRev в проект Rational Team Concert, используйте следующий поток работ:

Пользователь дает исходному агенту команду о переносе конкретного депо AccuRev.
Исходный агент использует клиента AccuRev для получения истории депо . История депо - это упорядоченный по времени список транзакций AccuRev в депо.
Исходный агент просматривает историю депо и создает пакеты, которые помещаются в почтовый ящик депо.
Каждый пакет описывает одну или несколько исходных транзакций и содержит необходимые сопутствующие материалы, например версии конкретных файлов.
Пользователь дает целевому агенту команду о мониторинге почтового ящика конкретного депо.
Целевой агент обрабатывает пакеты в почтовом ящике депо в порядке их создания.
Целевой агент создает область проекта Rational Team Concert при обработке первого пакета.
Целевой агент просматривает каждый пакет, преобразует исходные транзакции в транзакции Rational Team Concert и помещает их в область проекта Rational Team Concert.

При выполнении параллельного переноса нескольких депо AccuRev система миграции масштабируется.

Этот процесс продолжается до прекращения работы исходного и целевого агентов. Таким образом система миграции постепенно синхронизирует область проекта Rational Team Concert с депо AccuRev и затем поддерживает эту синхронизацию.

Описание пакета

Пакет - это элементарная единица взаимодействия между исходным и целевым агентами. В каждом пакете описывается одна или несколько исходных транзакций. Как показано на рисунке 4, пакет - это папка в общей файловой системе. Имена папок имеют формат Pkg- nnnnn , где nnnnn - это номер в возрастающем порядке. Такой принцип именования позволяет обрабатывать пакеты в порядке их создания.

Рисунок 4. Структура пакета

Структура пакета

Каждый пакет содержит файл описания пакета и, возможно, папку транзакций.

Файл описания пакета description.xml находится в корневой папке Pkg- nnnnn . Этот файл имеет следующую базовую структуру:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <package> // тело пакета </package>"

Тело пакета - содержит один или несколько описателей транзакций. Это XML-структуры, которые определяют операции в репозитории. Каждый описатель транзакции имеет уникальные отметку времени и идентификатор (ID) транзакции.
Описатели транзакций - перечисляются в файле описания пакета в соответствии с отметками времени (старые вверху).
Идентификатор транзакции - указывает папку транзакции, в которой находятся файлы, связанные с этой транзакцией.
Папка транзакции - содержит разреженное дерево каталогов. В ней находятся только папки и файлы, связанные с данной транзакцией.

Описатель транзакции

Исходный агент обрабатывает транзакции AccuRev для создания исходных транзакций. Целевой агент обрабатывает исходные транзакции для создания транзакций Rational Team Concert. Описатель транзакции представляет исходную транзакцию. Это XML-структура, которая определяет элементарную операцию в репозитории. В приведенном ниже листинге демонстрируется базовый синтаксис описателя транзакции. В квадратные скобки [ ] заключены необязательные теги.

<transaction xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance "xsi:type="streamData" user="AccuRev" type="xxxxxxxx" timeStamp="1129138647" id="1.0"> //Тело транзакции </transaction>

Заголовок транзакции содержит приведенные ниже теги. Теги xmlns и xsi можно игнорировать.

id - уникальный идентификатор транзакции. Это десятичное число.
timeStamp - время транзакции в исходном репозитории. Имеет 10-значное значение.
user - идентификатор пользователя, ответственного за транзакцию в исходном репозитории.
type - структура транзакции. Определяет дополнительные теги в заголовке транзакции и структуру тела транзакции.
comment - необязательный текст.

Исходные транзакции

Многие описатели транзакций в файле описания пакета не имеют тела. Они представляют транзакции AccuRev в истории депо, не нуждающиеся в миграции. Миграции подлежат только операции в потоке.

Исходные транзакции делятся на четыре типа:

chstream
mkstream
purge
promote
- defunct
- keep
- move
- undefunct

Для всех типов используется приведенный ниже синтаксис. В квадратные скобки [ ] заключены необязательные элементы.

chstream - изменяет атрибуты потока

<transaction type="chstream"
<streamID>10</streamID> <streamName>TestSCM-SqlServer</streamName> [<oldStreamName>TestSCM-SqlServer</oldStreamName>] <baseStreamName>TestSCM</baseStreamName> [<baseStreamType>normal</baseStreamType>] <isHidden>false</isHidden> <streamType>workspace</streamType> <basisTime>0</basisTime> </transaction>

<streamID> - уникальное имя, которое AccuRev назначает потоку.
<oldStreamName> - не требуется, если <streamType> принимает значение workspace.
<baseStreamType> - не требуется, если <streamType> принимает значение workspace.

mkstream - создает новый поток

<transaction type="mkstream" <streamID>1</streamID> <streamName>TestSCM</streamName> <isHidden>false</isHidden> Ok <streamType>normal</streamType> <basisTime>0</basisTime> </transaction>

<streamID> - уникальное имя, которое AccuRev назначает потоку.
<streamType> - может принимать значения normal, pass through и workspace.

purge - восстанавливает элементы последней введенной в поток версии

<transaction type="purge" <streamName>TestSCM_SanMateo</streamName> <streamType>normal</streamType> <baseStreamName>TestSCM</baseStreamName> <baseStreamType>normal</baseStreamType> <file>
<fileId>49127</fileId> <isDirectory>true</isDirectory> <path>\Purge_rename</path> <sequenceId>51.0</sequenceId> <fileStatus>keep</fileStatus> <comment>purged file</comment> <defectID>123</defectID> </file> </transaction>

<file> - определяет элемент. Может быть повторен для нескольких элементов.
<fileStatus> - определяет операцию над элементом.
<comment> и <defectID> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.

promote - отправляет изменения из одного потока в другой

Операция promote включает в себя четыре подтипа. Одна транзакция promote может иметь любое число этих подтипов в любой комбинации.

defunct
move
keep
undefunct

promote (defunct) - удаляет элемент из системы управления версиями

<transaction type="promote"> <toStream>TestSCM</toStream>
<file> <fileId>192</fileId> <isDirectory>true</isDirectory> <path>\HotfixComponents\Database\db2</path> <sequenceId>23.0</sequenceId> <fileStatus>defunct</fileStatus> [<comment>Example defunct</comment>] [<defectID>123</defectID>] </file> </transaction>

<file> - определяет элемент.
<fileStatus> - определяет операцию над элементом.
<comment> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.
<defectID> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.

promote (move) - переименовывает или повторно размещает элементы дерева исходного каталога

<transaction type="promote" > <file> <fileId>254</fileId> <isDirectory>true</isDirectory> <path>\HotfixComponents\Database\oracle\scripts</path> <source>\HotfixComponents\Database\oracle\scripts-kmd</source> <destination>\HotfixComponents\Database\oracle\scripts</destination> <sequenceId>39.0</sequenceId> <fileStatus>move</fileStatus> <comment>defunct</comment> <defectID>123</defectID> </file> <toStream>TestSCM</toStream> fromStream>Where</fromStream> </transaction>

<file> - определяет элемент.
<fileStatus> - определяет операцию над элементом.
<comment> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.
<defectID> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.

promote (keep) - предоставляет новую версию элемента

<transaction type="promote"> <toStream>TestSCM</toStream> <file> <fileId>264</fileId> <isDirectory>false</isDirectory> <path>\HotfixComponents\Database\sqlserver\scripts\yfs_table_not_sized_73_HF16.sql </path> <sequenceId>41.0</sequenceId> <fileStatus>keep</fileStatus> <mergedAgainstStreamName>TestSCM</mergedAgainstStreamName> <mergedAgainstStreamType>normal</mergedAgainstStreamType> <mergedAgainstBaseStreamName>TestSCM</mergedAgainstBaseStreamName> <mergedAgainstBaseStreamType>normal</mergedAgainstBaseStreamType> <comment>defunct</comment>] <defectID>123</defectID> </file> </transaction>

<file> - определяет элемент.
<fileStatus> - определяет операцию над элементом.
<mergedAgainst...> - указывает, что артефакт создан путем слияния.
<mergedAgainstBase...> - указывает основу (предка) для слияния.
<comment> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.
<defectID> - информация, вставляемая в свойства файла Rational Team Concert и комментарий Change Set.

promote (undefunct) - восстанавливает указанный элемент в системе управление версиями

<transaction type="promote"> <toStream>TestSCM</toStream> <fromStream>TestSCM</fromStream> <file> <fileId>44604</fileId> <isDirectory>false</isDirectory> <path>\buildallmigration.xml</path> <sequenceId>1401.0</sequenceId> <fileStatus>undefunct</fileStatus> </file> </transaction>

<file> - определяет элемент.
<fileStatus> - определяет операцию над элементом.

Файлы свойств

Все файлы свойств - это простые текстовые файлы. Строки, начинающиеся с #, являются комментариями. Исходный и целевой агенты используют разный синтаксис для файлов свойств.

Файл свойств исходного агента

Файл свойств определяет основные эксплуатационные параметры исходного агента. Он должен находиться в одной папке с исполняемым файлом исходного агента. Пример синтаксиса показан ниже.

# # Путь в файловой системе к почтовому ящику # mailbox_dir=<полный путь к каталогу почтового ящика> mailbox_dir=C:\\mailbox\\ # # Максимальное число транзакций в пакете package # transactions_per_package=<максимальное число транзакций> transactions_per_package=100 # # папки, исключаемые из миграции Foundation_folders_to_exclude=\\this\\, \\that\\, \\the_other\\ # # Частота проверки перенесенного депо на новые транзакции # refresh_transaction_mins=<период> refresh_transaction_mins=5 # # Кому отправлять уведомления по электронной почте? # email_receivers=<адрес электронной почты>[, <email_addr> …] email_receivers=person1@in.ibm.com,person2@us.ibm.com # # Уровень log-сообщений при миграции каждого депо. Это свойство # на общий уровень, который всегда установлен в ALL. # logging_level=<ALL / FINE / INFO / WARNING / SEVERE> logging_level=INFO # # Число log-файлов для записи до переноса (минимальное значение - 1) # log_file_count=<число файлов> log_file_count=50 # # Максимальный размер log-файла в байтах (минимальное значение - 0) # log_file_size=<размер в байтах> log_file_size=500000

Файл свойств целевого агента

Этот файл определяет основные эксплуатационные параметры целевого агента. Он должен находиться в одной папке с исполняемым файлом целевого агента. Пример синтаксиса показан ниже.

# # Информации о подключении к Jazz Server # rtc_repository_Address=<URI репозитория jazz> # rtc_username=<IDпользователя> # rtc_password=<пароль> rtc_repository_Address=https\://jazz705.hursley.ibm.com\:9443/ccm rtc_username=Y9AB2Y866@nomail.relay.ibm.com rtc_password=xxxxxxxx # # Запланированное время простоя Jazz Server # downtime=<{24-часовой формат}-{24-часовой формат}> downtime=03:00-04:00 # # Путь в файловой системе к почтовому ящику # mailbox_dir=<полный путь к каталогу почтового ящика> mailbox_dir=C:\\mailbox\\ # # RTC Process Template # rtc_process_template_id="<template>.process.ibm.com" process_template="scrum2.process.ibm.com" # # Частота проверки новых почтовых ящиков депо # refresh_depots_mins=<период> refresh_depots_mins=5 # # Частота проверки перенесенного почтового ящика депо на новые пакеты # refresh_transaction_mins=<период> refresh_transaction_mins=5 # # Кому отправлять уведомления по электронной почте? # email_receivers=<адрес электронной почты>[, <email_addr> …] email_receivers=person1@in.ibm.com,person2@us.ibm.com # # Уровень log-сообщений при миграции каждого депо. Это свойство # не влияет на общий уровень, который всегда установлен в ALL. # logging_level=<ALL / FINE / INFO / WARNING / SEVERE> logging_level=INFO # # Число log-файлов для записи до переноса (минимальное значение - 1) # log_file_count=<число файлов> log_file_count=50 # # Максимальный размер log-файла в байтах (минимальное значение - 0) # log_file_size=<размер в байтах> log_file_size=500000

Исходный и целевой агенты создают log-файлы. Они сохраняются в той же общей файловой системе, что и почтовый ящик. Записи в log-файлах имеют следующий синтаксис:

{Date} {SourceClassName} {SourceMethodName} {Log Message Level} {Log Message}

Date - отметка времени (дата и время) записи.
SourceClassName и SourceMethodName - определяют местоположение в коде.
Log Message Level (уровень регистрации сообщений):
- FINE - подробная информация о транзакциях.
- INFO - общая информация о транзакциях.
- WARNING - только не фатальные ошибки.
- SEVERE - только фатальные ошибки (с трассировкой стека).
Log Message - текстовая строка.

Описание исходного агента

Показанный на рисунке 5 исходный агент - это Java-приложение, выполняющееся на исходной клиентской машине. Оно управляется с помощью простого пользовательского интерфейса и глобальных параметров в файле свойств.

Рисунок 5. Выполнение депо в целевом агенте

Выполнение депо в целевом агенте

Исходная клиентская машина должна иметь сетевой доступ к серверу AccuRev. На исходной клиентской машине также должен выполняться клиент AccuRev. Он должен иметь доступ к репозиторию AccuRev. Файл свойств исходного агента должен находиться в одном каталоге с исполняемым файлом.

Главной задачей исходного агента является создание потока пакетов с описателями транзакций, управляющими целевым агентом при построении области проекта в целевом репозитории Rational Team Concert.

Для выполнения этой задачи исходный агент анализирует историю депо AccuRev, которая представляет собой последовательность транзакция, использовавшихся при создании этого депо.

Исходный агент может параллельно обрабатывать несколько депо. В описатели транзакций могут преобразовываться следующие транзакции AccuRev:

chstream
defunct
mkstream
move
promote
purge (при использовании для потока)
undefunct

Историю депо предоставляет AccuRev-команда hist. Команда cat позволяет извлечь из репозитория управляемые версиями элементы и добавить их в пакет.

Описание целевого агента

Показанный на рисунке 6 целевой агент - это Java-приложение, выполняющееся на целевой клиентской машине. Оно управляется с помощью простого пользовательского интерфейса и глобальных параметров в файле свойств.

Рисунок 6. Выполнение депо в целевом агенте

Выполнение депо в целевом агенте

Целевая клиентская машина должна иметь сетевой доступ к серверу Rational Team Concert. Идентификатор (ID) приложения, определенный в файле свойств целевого агента, и пароль должны быть действительны для сервера Rational Team Concert. На сервере Rational Team Concert должен быть развернут шаблон процесса. Файл свойств целевого агента должен находиться в одном каталоге с исполняемым файлом.

Главной задачей целевого агента является последовательная обработка пакетов, появляющихся в почтовом ящике депо. Целевой агент может параллельно обрабатывать несколько почтовых ящиков депо. Целевой агент пересоздает депо AccuRev как область проекта Rational Team Concert, используя исходные транзакции в пакетах.

Примечание. Имя депо AccuRev используется в качестве имени почтового ящика депо. В качестве имени целевой области проекта Rational Team Concert используется имя почтового ящика депо. Поэтому область проекта Rational Team Concert имеет то же имя, что и депо AccuRev. Целевой агент использует программный интерфейс Rational Team Concert Java API для синтеза транзакций Rational Team Concert из исходных транзакций.

Взаимодействие между исходным и целевым агентами

Интерфейсом для взаимодействия между исходным и целевым агентами является папка общей файловой системы под именем Mailbox (см. рисунок 7). Эта папка содержит папку Logs и несколько папок почтовых ящиков депо.

Рисунок 7. Папка MailBox

Папка MailBox

Платформы исходного и целевого агентов

Исходный и целевой агенты не зависят от платформы. Тем не менее они должны выполняться на одной платформе (Windows™ или Linux®), чтобы избежать проблем, вызванных различиями платформ в работе с текстовыми файлами:

Разделители пути:
\ (Windows)
/ (Linux)
Маркеры конца строки:
<CR><LF> (Windows)
<LF> (Linux)

Координация исходного и целевого агентов

Согласно схеме исходный и целевой агенты работают асинхронно. Координация агентов выполняется вручную. Два пользовательских интерфейса позволяют независимо выполнять запуск, останов и перезапуск миграций.

Независимые останов и запуск миграции на любом агенте не являются проблемой. Эффект останова миграции зависит от агента (исходный или целевой), на котором останов выполнен.

Если остановить миграцию на целевом агенте, исходный агент будет добавлять пакеты в почтовый ящик, пока не завершит миграцию или не остановится по причине заполнения почтового ящика.
Если остановить миграцию на исходном агенте, целевой агент будет обрабатывать пакеты из почтового ящика, пока тот не опустеет.

На любом агенте миграцию можно перезапустить только после ее останова. Однако следует позаботиться о таком перезапуске миграции, останов которой выполняется на другом агенте. Эффект останова миграции зависит от агента (исходный или целевой), на котором останов выполнен.

При перезапуске миграции на исходном агенте ее состояние принимает значение Resetting. Затем переменные состояния миграции в файле свойств сбрасываются, папки пакетов в почтовом ящике очищаются и состояние миграции принимает значение Ready. При перезапуске миграции обработка истории депо начинается сначала.
При перезапуске миграции на целевом агенте ее состояние принимает значение Resetting. Переменные состояния миграции в файле свойств сбрасываются и область проекта Rational Team Concert переименовывается (путем добавления Archived и отметки времени) до архивирования. Затем состояние миграции меняется на Ready. При перезапуске миграции обработка пакетов начинается сначала.

Уведомления по электронной почте

Файлы свойств исходного и целевого агентов содержат список email_receivers. Это список разделенных запятыми адресов электронной почты. Агенты будут отправлять на эти адреса сообщения об остановах миграции из-за фатальных ошибок.

Устранение проблем исходного агента

В устранении проблем исходного агента помогут приведенные ниже советы и решения.

Не все рабочие области переносятся

Рабочие области могут не переноситься по двум причинам:

Рабочие области AccuRev состоят из двух частей. Если поток рабочей области находится в репозитории, а дерево рабочей области находится в файловой системе на рабочей станции пользователя, дерево будет недоступно для системы миграции.
Каждый пользователь AccuRev может иметь много рабочих областей. Поскольку перенос всех рабочих областей существенно увеличивает затраты на миграцию, система миграции может не перенести некоторые рабочие области.

Если для доступа к AccuRev и Rational Team Concert используются одна и та же рабочая станция, пользователи могут перенести свои рабочие области следующим образом:

Создайте рабочую область Rational Team Concert, состоящую из рабочей области репозитория и персональной рабочей области.
Загрузите рабочую область Rational Team Concert из потока Rational Team Concert, перенесенную из потока AccuRev, поддерживающего пользовательскую рабочую область AccuRev.
Замените артефакты персональной рабочей области Rational Team Concert активными артефактами дерева рабочей области AccuRev.
Проверьте итоговый набор изменений.

Игнорируемые транзакции AccuRev

Исходный агент не обрабатывает приведенные ниже виды транзакций AccuRev, поскольку они не подходят для миграции.

Транзакция	Описание
`archive`	Используется для подготовки файлов к переносу в автономное хранилище.
`check out`	Используется для блокировки артефакта, исключающей обновление.
`compress`	Альтернативный вид архивирования.
`defcomp`	Используется для указания включения/исключения файлов при обновлении рабочей области.
`dispatch`	Используется для передачи информации в AccuWork.
`purge`	Отменяет изменения рабочей области пользователя. Исходный агент обрабатывает тип purge, когда он применяется к потоку.
`unarchive`	Отменяет архивирование.

Обрабатываются транзакции add, move, defunct и undefunct.

Изменение последовательности транзакций

AccuRev имеет функцию TimeSafe, позволяющую восстановить конфигурацию репозитория в любой момент времени. Это означает, что многие команды имеют параметр time spec.

Например, mkstream с параметром time spec позволяет получить снимок потока, содержащий конфигурацию потока в любой момент времени в промежутке между временем создания потока и текущим временем. При переходе в историю депо транзакция mkstream получает отметку текущего времени. Параметр time spec содержится в теге basis time транзакции.

В Rational Team Concert нет этой функции, поэтому исходный агент начинает миграцию с получения полной истории депо. Он выполняет начальное сканирование истории для поиска транзакций, у которых basis time отличается от отметки времени. Из этих транзакций образуется FIFO-список (обрабатывается в порядке поступления).

Затем исходный агент начинает обработку истории депо. Следующая транзакция, подлежащая обработке, определяется путем сравнения следующей транзакции в истории депо с basis time транзакции, возглавляющей FIFO-список. Обрабатывается более ранняя транзакция.

В результате целевому агенту предоставляется поток транзакций, упорядоченный по basis time. В данном примере транзакция mkstream перемещается таким образом, чтобы целевой агент мог обработать ее в настоящий момент.

Повторное выполнение миграции

В процессе миграции исходный агент создает пакеты из истории транзакций AccuRev. Каждый пакет содержит файл описания пакета и папку для каждой транзакции, которая обновила один или несколько файлов исходного кода. В папке транзакции хранятся соответствующие версии файлов исходного кода.

Извлечение версий конкретного файла является затратным по времени элементом миграции. Если миграция останавливается и перезапускается, файлы описания пакетов восстанавливаются. Перед извлечением версии файла исходный агент проверяет папку транзакции на наличие этой версии. При ее наличии извлечение не выполняется.

Этот процесс делает повторную миграцию более быстрой, чем первоначальная миграция.

Обработка исключительных ситуаций

Многие исключительные ситуации могут стать причиной неудачной миграции, например:

Потеря доступа к папке почтового ящика.
Переполнение почтового ящика депо.
Потеря подключения к серверу AccuRev Server.

Исходный агент не пытается выполнить восстановление после сбоя любого вида, а просто регистрирует событие и останавливает миграцию. Для повторного запуска требуется ручное вмешательство.

Описание операций целевого агента

В Rational Team Concert управление некоторыми операциями и атрибутами целевого агента осуществляется иначе, чем в AccuRev. Чтобы учесть эти различия, сконфигурируйте Rational Team Concert для обработки настроек AccuRev.

Идентификатор (ID) приложения

Целевой агент работает с Rational Team Concert, используя идентификатор приложения. Обновления в репозитории Rational Team Concert, выполненные системой миграции, относятся к этому идентификатору.

Кроме того, обновления в репозитории Rational Team Concert получают отметку времени их выполнения целевым агентом.

Сохранение информации AccuRev

Часть информации нельзя перенести в репозиторий Rational Team Concert напрямую, например:

Идентификатор пользователя AccuRev, к которому относится транзакция.
Идентификатор транзакции AccuRev.
Отметка времени транзакции AccuRev.
Комментарий к транзакции AccuRev.
Номер выпуска AccuWork (либо номер записи HP Quality Center или оба), связанный с транзакцией.

Эта информация передается в целевой агент в описателе транзакции и сохраняется в Rational Team Concert в виде комментария Change Set или свойств файла.

Сквозные потоки

AccuRev поддерживает специальный вид потока, именуемый сквозным потоком. Изменения в сквозном потоке попадают прямо в родительский поток. Сквозные потоки используются в основном для управления иерархией потоков. Переподчинить сквозной поток намного проще, чем переподчинить все входящие в него потоки и рабочие области.

Rational Team Concert не поддерживает сквозные потоки. Вместо этого используется следующий способ взаимодействия с ними целевого агент. Транзакция mkstream указывает, что поток является сквозным. Целевой агент создает поток и добавляет _passthrough к его имени.

В результате поток появляется в иерархии потоков области проекта Rational Team Concert и помечается как сквозной. Этот способ позволяет впоследствии удалить этот поток.

Скрытые потоки

Графический интерфейс AccuRev позволяет скрывать потоки. Это удобство представления, а не атрибут потока.

В Rational Team Concert каждый поток имеет атрибут visibility. Он делает поток видимым в конкретной области Team Areas.

Для системы миграции скрытый поток ничем не отличается от любого другого потока. Поток, скрытый в AccuRev, становится видимым в области проекта Rational Team Concert. После выполнения миграции в Rational Team Concert поток можно скрыть или удалить.

Наследование

В AccuRev перенос элемента (файла или каталога) делает его активным в целевом потоке и неактивным в исходном потоке или рабочей области. Если целевой поток является частью иерархии, активный элемент сразу становится доступным для дочерних динамических потоков первого уровня.

Элемент автоматически наследуется дочерним потоком, если он неактивен в этом потоке. После наследования элемент в потоке активизируется и может наследоваться дочерними потоками следующего уровня.

Rational Team Concert не может переносить изменения через иерархию потока подобным образом, поэтому целевой агент должен имитировать поведение AccuRev. Целевой агент выполняет транзакцию promote в целевой поток как транзакцию deliver Rational Team Concert. Данная транзакция имеет один набор изменений на элемент, но доставка является атомарной.

Эти наборы изменений становятся предстоящими входными изменениями для любого потока, входящего в целевой поток. Затем целевой агент просматривает эти потоки и доставляет наборы изменения по месту назначения. Этот процесс распространяется вниз по иерархии потоков.

Обработка исключительных ситуаций

Следующие исключительные ситуации могут стать причиной неудачной миграции:

Потеря доступа к папке почтового ящика.
Потеря подключения к серверу Jazz и другим критически важным серверам.

Целевой агент не пытается выполнить восстановление после сбоя любого вида, а просто регистрирует событие и останавливает миграцию. Для повторного запуска требуется ручное вмешательство.

Задачи после миграции

Система миграции создает область проекта Rational Team Concert и заполняет ее информацией из депо AccuRev. Все области проекта создаются из-за одного шаблона. Однако есть несколько аспектов конфигурации Rational Team Concert, которые нельзя создать с помощью шаблона.

Область проекта. Для завершения конфигурирования области проекта необходимо назначить администраторов и членов проекта.
Области групп. Для завершения конфигурирования каждой области группы необходимо назначить членов группы.
Область проекта. Для завершения конфигурирования проекта необходимо назначить администраторов и членов проекта.
Область группы. Для завершения конфигурирования области группы необходимо назначить членов группы.

После миграции выполните следующие проверки в потоках:

Соответствует ли иерархия потоков Rational Team Concert иерархии потоков AccuRev?
Совпадает ли содержимое потока Rational Team Concert с содержимым эквивалентного потока AccuRev?
Соответствуют ли наборы исходящих изменений потока Rational Team Concert списку активных файлов потока AccuRev.
Для завершения конфигурирования иерархии потоков выполните следующие действия:

Установите атрибуты владения и видимости потока Rational Team Concert.
Удалите сквозные потоки (не обязательно).
Удалите или измените атрибуты владения и видимости области группы администраторов только для тех потоков, которые в данный момент скрыты в AccuRev, но присутствуют в Rational Team Concert (не обязательно). Поскольку в Rational Team Concert скрыть потоки нельзя, убедитесь в правильной настройке целей потоков.

Заключение

В этой статье демонстрируется перенос исходного кода из AccuRev в Rational Team Concert с историей и без нее. В ней описываются различия в создании потоков в каждом инструменте и приводятся рекомендации по их согласованию. Проверка, выполненная после миграции, гарантирует успешный перенос исходного кода.