Нет простого ответа на ваш вопрос, так как понятия не обязательно применяются. Это означает, что ответ тоже должен углубляться в фон.
Спецификация конфигурации является ключом к пониманию того, как все будет работать в данный момент (catcs). Просмотр фактических имен версий файлов и истории версий (описать, lshistory) - это еще один ключ к пониманию того, как все работает во время создания ветки или версии.
Ветвь существует независимо от файлов в ней. Для разных файлов одно и то же имя ветки может появляться в разных местах в структуре ветвления. Ветвь не обязательно создается из помеченной версии файла (хотя иногда это так). Аналогично, ярлыки существуют независимо от файлов, которые помечены.
Например, рассмотрим файл, который я должен сейчас просматривать (имена замаскированы, но репрезентативны):
- xyzscan.c @@ / Основной / TEMP.newfeat.it1 / TEMP.newfeat.it2 / TEMP.newfeat.it3 / 3
Изучив историю, я вижу, что ветка TEMP.newfeat.it1 была создана из версии xyzscan.c @@ / main / 89; это не была помеченная версия, потому что предыдущий пакет исправлений использовал xyzscan.c @@ / main / 88 (помеченный product-6.54.03, среди прочего; файл не был изменен для нескольких выпусков, не говоря уже о пакетах исправлений). Версия / 89 была (незначительным) исправлением ошибки с предыдущей помеченной версии.
Произошло 3 итерации этой новой функции. Текущая спецификация конфигурации выглядит примерно так:
element * CHECKEDOUT
element * .../TEMP.newfeat.it3/LATEST
mkbranch TEMP.newfeat.it3 -override
element * .../TEMP.newfeat.it2/LATEST
mkbranch TEMP.newfeat.it2 -override # Redundant
element * .../TEMP.newfeat.it1/LATEST
mkbranch TEMP.newfeat.it1 -override # Redundant
element /vobs/product/... /main/LATEST
include /atria_release/cspecs/otherprod/2.34/otherprod-2.34.05
element * /main/LATEST
Вторая и третья строки 'mkbranch' теперь избыточны, но были актуальны, когда их ветвь была самой последней.
В нашей схеме нет меток на ветвях TEMP. * (И обычным инженерам не разрешается создавать ветки, которые не запускают "TEMP."; Это обеспечивается скриптами запуска).
Файл xyzscan.c изменялся в каждой итерации. Используя «описать», я вижу, что:
xyzscan.c @@ / main / TEMP.newfeat.it1 / TEMP.newfeat.it2 / TEMP.newfeat.it3 / 0 был разветвлен от
xyzscan.c @@ / главная / TEMP.newfeat.it1 / TEMP.newfeat.it2 / 2
xyzscan.c @@ / main / TEMP.newfeat.it1 / TEMP.newfeat.it2 / 0 был разветвлен от xyzscan.c @@ / main / TEMP.newfeat.it1 / 7.
Но если я посмотрю на другой файл:
- xyzread.c @@ / главный // TEMP.newfeat.it3 / 1
Я вижу, что это не было изменено до итерации 3 - для этого файла нет ветви TEMP.newfeat.it1 или TEMP.newfeat.it2. Кроме того, это не проблема.
Вопрос задает:
У меня есть представление, созданное для дочерней ветви. Для заданного имени дочерней ветви можно ли узнать родительскую ветвь и базовую метку, из которой была создана дочерняя ветвь.
Имея файл в представлении, вы можете запустить 'cleartool description', возможно, с опцией '-s' (short), чтобы получить его номер версии. В моем примере это может быть:
Чтобы узнать, откуда он был разветвлен, вам нужно взглянуть на версию '/ 0' в ветке, которая по содержанию идентична версии в ветке TEMP.newfeat.it2, из которой она была разветвлена. Затем вам нужно просмотреть полное описание версии '/ 0', чтобы увидеть, какой была предшествующая версия ('-s' теперь не помогает). Вот как я обнаружил, что предыдущая версия была:
- xyzscan.c @@ / Основной / TEMP.newfeat.it1 / TEMP.newfeat.it2 / 2
Повторите движение назад. Вы можете увидеть метки, которые относятся к версии, из которой TEMP.newfeat.it3 был разветвлен, в (полном) выводе «description». Однако эти метки могли быть применены с момента создания ветки.
В общем случае (но не в этом примере) в ветке, такой как TEMP.newfeat.it2, могут быть более поздние версии после версии, в которой был разветвлен TEMP.newfeat.it3. Это всегда приводит к вопросу о том, нужно ли объединять дополнительные изменения в ветке TEMP.newfeat.it2 до ветки TEMP.newfeat.it3 - к счастью, ClearCase довольно хорош в отношении слияний и отслеживания слияний.