Ответ 1
Самая опасная ловушка:
Как только компонент определен, вы не можете перемещать элемент за пределами этого компонента (его можно скопировать и воссоздать в другом месте, но вы потеряете его историю)
Самая полезная передовая практика:
Хорошо понять природу компонента UCM: это о когерентности.
Компонент представляет собой набор файлов, который:
- развивается как единое целое,
- помечен как базовый, в целом,
- является разветвленным в целом.
Если вы можете сделать эволюцию, не касаясь другой группы файлов, возможно, у вас есть два компонента.
Пример компонентов:
- приложение (или автономная часть приложения)
- техническая библиотека
- пакетный набор файлов (для выпуска)
Один документ, который должен помочь вам определить компоненты, - это Прикладная архитектура (которая берет бизнес и функциональные спецификации и проектирует их на приложениях, которые затем будут указаны на техническом уровне и реализованы).
Когда все эти компоненты определены, у вас есть два подхода к управлению ими:
-
системный подход (каждый компонент доступен для записи в проекте UCM): полезно для запуска проекта, но громоздкий с унаследованным проектом: вам не нужно ставить базовую линию на каждый компонентов просто потому, что в одном из этих компонентов было изменено 3 файла.
-
компонентный подход: один или два записываемых компонента, остальное - только как немодифицируемый компонент. Это масштабируемый подход, позволяющий вам определить один проект для каждого компонента для разработки с "фиксированной конфигурацией" (то есть "другими базовыми линиями", представляющими фиксированные состояния немодифицируемых компонентов, которые необходимы для компиляции Модифицируемая. Вы можете в любой момент изменить эту конфигурацию, то есть вы можете переустанавливать базовые линии фундамента немодифицируемого компонента, когда захотите).
Вы можете определить столько проектов и потоков, которые вы хотите, что позволит вам легко визуализировать рабочий процесс слияния.
Помните: поток представляет собой процесс разработки.
Не вызывайте Stream после ресурса (например, VonC_stream), но после задачи или набора задач, которые необходимо выполнить в этом потоке (как в APP_LCH_R32_Dev: Разработка для 32-й версии моего приложения Launcher)
Примечание: UCM - это всего лишь некоторые метаданные поверх ClearCase: даже если группа файлов определена как компонент UCM, ничто не мешает вам создавать классические ветки, контрольные проверки или проверки (не в UCM) просмотров).
Существует ли опасность создания слишком большого количества мелкозернистых компонентов или слишком много зависимостей между компонентами?
Да, поэтому важна Аппликационная архитектура. Опять же, как только компонент определен, вы не можете перемещать элементы между этими компонентами.
Еще одна информация о компонентах - их макет:
myVob
myComponent1
myComponent2
myComponent3
Корневой компонент всегда находится на первом уровне ниже Vob.
Вы также можете определить компонент как все Vob, но я бы не рекомендовал его (добавление Vob ставит ударение на ваш VOB-сервер. Добавление каталога в существующем Vob ничего не стоит)
Это означает, что если вы определите некоторые технические библиотеки как компоненты, вы не сможете:
myLibs
Apache
ant
xalan
xerces
но придется делать:
myLibs
apapche_ant
apache_xalan
apache_xerces
Заключительное предупреждение: зависимость (истинный знак системы управления конфигурацией)
Одним из основных преимуществ UCM (или, как я думал, в то время - 2003) является зависимость.
Если A зависит от B, и я помещаю A в свой проект, он автоматически включит B в тот же проект.
Магия.
Но он сломан.
- Во-первых, никогда не зависимо от корневой базы (корневой компонент - это набор файлов). Он будет разбит при первом перекрытии:
A1
B1
B2
Здесь вам нужно B2 продолжить строительство A, но A начинается с A1 на основе B1: B2 переопределяет B1. Как только вы положите базовую линию на A (A2), она закончена. Вы больше не сможете менять B. A базовый уровень паразита (называемый A2!?) будет помещен в компонент (не изменяемый!) B из-за перекрытия.
- Всегда включайте свои зависимости в безвирусном компоненте
ADep1
A1
BDep1
B1
BDep2
B2
Здесь у вас есть бескоронные компоненты ADep и BDep (rootless-компонент - это специальный компонент, который объединяет другие компоненты без корневого или корневого)
У вас все еще есть переопределение, но на этот раз между компонентами без корней.
Это все равно сделает базовый уровень паразита (на BDep, называемый A2), но по крайней мере вы сможете снова перегрузить BDep2 в другие базовые линии (BDep3, BDep4...)
Подробнее об этом Incoherences и несоответствия ClearCase UCM, Рациональные контр-аргументы здесь (и только после этого их сообщение, доказательство того, что их аргументы не очень хороши, чтобы сказать меньше).
Читайте также Как использовать функции Clearcases