В ClearCase требуется вызов CLI для получения списка всех ревизий. - PullRequest
Новая
       58

В ClearCase требуется вызов CLI для получения списка всех ревизий.

1 голос
/ 23 февраля 2020

Я пытаюсь добавить поддержку чтения репозиториев ClearCase в reposurgeon . Я смог разобраться в большей части того, что, по моему мнению, мне нужно, но документация - это огромная куча запутанных деталей, которые оставляют неясным один основной вопрос. Как мне перечислить все ревизии в CC репозитории?

Минимум, что мне нужно, это упорядоченная по времени последовательность строк, каждая из которых содержит идентификатор ревизии (путь, ветвь, уровень ревизии) и его родительскую ревизию. ID.

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

Было бы удобнее, если бы я мог получить листинг из четырех столбцов: ID ревизии, ID родителя, имя коммиттера, и отметка времени. Учитывая это, массирование отчета в поток быстрого импорта git будет почти тривиальным.

Мне все еще немного неясно, как VOB связаны с репозиториями одного проекта в других системах, поэтому вызов для «указанный VOB» и другой для «всех VOB» будут приветствоваться.

Следствием полезного ответа на этот вопрос является то, что я сделаю джейлбрейк ClearCase, решив проблему переноса полных историй из него в Git.

Ответы [ 2 ]

0 голосов
/ 01 марта 2020

Для базового прозрачного (на windows) перечисления ревизий можно сделать двумя способами:

  • clearexport_ccase

    Инструмент clearexport_ccase записывает текстовый файл с большей частью релевантной информации одного VOB (одного хранилища). Насколько мне известно, формат не описывается IBM.

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

  • cleartool lshistory

    Подкоманда lshistory cleartool записывает текстовый файл (формат может быть задан как параметр), который, кажется, содержит всю метаинформацию версии версионных элементов.

    Неясно, содержит ли он информацию о слиянии элементов.

С обоими выходными данными вы не получаете сами версионные элементы, а только базу данных дорожка. Чтобы извлечь файл из базы данных, вы должны использовать cleartool get .

  • Поскольку базовый прозрачный регистр ориентирован на файл, каждый файл сам версионируется.
  • Создание наборов изменений из файла, версии должны быть сделаны путем объединения всех версионных файлов путем просмотра ветки, тега, автора, регистрации msg, времени регистрации ...

  • Слияние выполняется по файлам и может быть выполнено реальное слияние или рисование стрелки слияния, что означает отображение слияния в дереве ревизий файла.

    Слияние можно изменить, рисуя стрелки слияния в дереве версий файла.

  • Кроме того, у вас есть конфигурация spe c, которая определяет, какие версионные элементы вы видите в своем представлении хранилища; например, они определяют, какую ветку вы видите по вашему мнению. (Возможно, их можно игнорировать при преобразовании VOB.)

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

Существует конвертер ClearCase в SVN , который работает для базового сценария, который преобразует версии файлов в наборы изменений. Так что это кажется возможным.

0 голосов
/ 23 февраля 2020

Во-первых, проверьте мой старый ответ " Каковы базовые c концепции в чистом виде, которые должен знать каждый разработчик ". См. Также « Преимущества / недостатки ClearCase »

TLDR: Clearcase основан на файлах, а не на базе ревизий репозитория.

A cleartool lsvtree будет перечислять ревизии для одного файла.

Но только (полный) базовых показателей UCM даст что-то похожее на ревизию, и только для компонента UCM в Vob .

Было бы удобнее, если бы я мог получить список из четырех столбцов: идентификатор редакции, идентификатор родителя, имя коммиттера и метку времени. Учитывая это, массирование отчета в поток быстрого импорта git будет почти тривиальным.

Это будет cleartool lsbl -fmt с использованием fmt_ccase синтаксис 

cleartool lsbl -fmt "%n %[owner]Fp %d"

Примечание: получение "родительской" базовой линии более сложно: см. " Как получить предыдущую базовую линию из потока ".

См. подробнее о том, как перенести ClearCase на Git. Без UCM это было бы беспорядком.

...