В чем разница между полным базовым уровнем и дополнительным базовым уровнем в Clearcase UCM?

Я применил полную базу для своего выпуска. например Базовая линия «MYProj_2.0.0.20».

Затем команда тестирования нашла серьезную проблему. Чтобы исправить это, команда разработчиков внесла несколько изменений.

После завершения сборки я снова применил тот же базовый план «MYProj_2.0.0.20. Но на этот раз я применил инкрементный базовый план. В соответствии с UCM базовый план MYProj_2.0.0.20 был преобразован как MYProj_2.0.0.20.3452 (некоторые случайные номер в конце, чтобы сделать его уникальным).

Теперь, если я рассматриваю MYProj_2.0.0.20.3452 как базовый уровень выпуска, будет ли он содержать все изменения или только изменения (изменение дельты между «MYProj_2.0.0.20» и «MYProj_2.0.0.20.3452»).

Пожалуйста, поясните мне.


baseline clearcase clearcase-ucm
person Samselvaprabu    schedule 14.03.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Он будет содержать все изменения.

За исключением инкрементальных базовых показателей, эти изменения будут вычисляться путем добавления:

  • уникальные модификации, внесенные несколькими изменениями (вот что такое «инкрементная базовая линия»: метка, установленная только на новых версиях по сравнению с предыдущей базовой линией)
  • все другие изменения уже ссылаются на предыдущие базовые планы вплоть до полной базовой линии

См. "Типы базовых показателей ":

  • Полный базовый план - это базовый план, который вы создаете, записывая все версии всех элементов ниже корневого каталога компонента.
  • Добавочный базовый план - это базовый план, который вы создаете, записывая последний полный базовый план и те версии элементов, которые изменились с момента создания последнего полного базового плана.

(есть также «базовые параметры контрольной точки», как подробно описано в «об базовых показателях ClearCase ", созданных автоматически с помощью операций доставки и перебазирования, но вам не нужно беспокоиться об этом прямо сейчас)

Вот почему я всегда предпочитаю полную базовую линию: все дельта-операции (например, «сравнение с другой базовой линией») выполняются быстрее, если последняя базовая линия является полной.
Аргументом в пользу инкрементных базовых показателей является то, что они быстрее create (из-за меньшего количества версий, на которые нужно установить базовый уровень).
Но если ваш компонент UCM настолько велик, что ставить метку на все его версии слишком долго, возможно, ваш компонент вообще слишком велик.

Обратите внимание, что вы всегда можете обновить инкрементный базовый план до полного базового плана.

Также обратите внимание, что у вас есть разница между:

  • название базовой линии (здесь "MYProj_2.0.0.20": вы можете указать столько базовых показателей "MYProj_2.0.0.20", сколько хотите)
  • идентификатор базовой линии (всегда уникален: если "MYProj_2.0.0.20" уже взято, ClearCase сгенерирует несколько чисел в конце: "MYProj_2.0.0.20.3452")
person VonC    schedule 14.03.2012
comment
Еще один момент в пользу дополнительных базовых показателей - они, очевидно, имеют тенденцию занимать меньше места в метаданных. Таким образом, в огромных проектах разработки (и, как следствие, огромных компонентах UCM) с ежедневными базовыми планами + сборками более 5 лет это имеет огромное значение в управлении размерами VOB. - person Pulak Agrawal; 20.03.2012
comment
@PulakAgrawal Каждый раз, когда я сталкиваюсь с подобной проблемой, я немедленно извлекаю часть этого огромного компонента в новый. Огромный компонент побеждает цель компонента UCM, которая состоит в том, чтобы определять согласованный набор файлов: его размер должен быть ограниченным и разумным. - person VonC; 20.03.2012
comment
@PulakAgrawal, как говорится, ваш комментарий иллюстрирует один из основных потоков ClearCase. Это. Делает. Нет. Масштаб. - person VonC; 20.03.2012
comment
@VonC Ссылка на типы базовых показателей разорвана. Вот он: Типы базовых показателей - person javaPlease42; 22.05.2015
comment
@ javaPlease42 Спасибо. Я соответствующим образом отредактировал ответ. - person VonC; 22.05.2015