ClearCase хочет объединить неизмененные файлы после доставки в альтернативную цель
==================================================================================

 При использовании Rational ClearCase v. 7.0.1.1 с UCM у меня возникла проблема при использовании функциональности ClearCase «Доставить из потока в альтернативную цель».

 Представьте, что у нас есть один поток интеграции проектов и два потока разработчиков A и B, полученных из него. Теперь я изменяю файл в потоке A. Я хочу, чтобы поток-владелец delevoper мог использовать мою работу, пока мне не нужно было доставлять файл в поток интеграции, поэтому я доставляю из потока A в альтернативный целевой поток B.

Все идет нормально. Я продолжаю вносить другое изменение в файл, но разработчику потока B это изменение не нужно, поэтому я не передаю его ему.

 Через некоторое время я доставлю свою работу в основной интеграционный поток. Это прекрасно работает, хотя мне интересно, почему ClearCase помечает слияние как обычное «Объединено» вместо «Объединено (тривиально)» - никто, кроме меня, не вносил изменения в файл.

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

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

 Путаница продолжается, когда после разрешения слияния и завершения ребазинга разработчик B хочет выполнить доставку в основной поток интеграции. Помимо деятельности, которую я ему первоначально поставил, ему также предлагается выполнить операцию с именем rebase \_..., которую я никогда не ожидал бы предложить для доставки.

 Я что-то здесь упустил? Правильно ли мы используем ClearCase или это известное ограничение / ошибка? Кто-нибудь сталкивался с этой функциональностью?

Заранее спасибо за вашу помощь

 Ян

 когда я смотрю на дерево версий, источник конфликта во время перебазирования становится ясен:

![]()

 Когда ты перечитываешь путь[ClearCase 3-way merge работает](https://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645771#645771), вы видите, что нужно вернуться в дерево версий, чтобы найти общего предка:

 источник (Int / 2) пункт назначения (B / 1) Этот общий предок - Int / 1

 Вполне возможно, что общая черта изменилась между этими двумя версиями с тех пор:

 источник последней ребазы (Int / 2) взят из A / 3 пункт назначения последней перебазировки (B / 1) прибывает из A / 2 общий предок (Int / 1) происходит от A / 1 Если общая линия была изменена (из A / 1) как в A / 2, так и в A / 3 ... есть причина для ручного разрешения слияния прямо здесь!

 (Сейчас проверяю)

Понял! Конфликт достигнут!

 Продолжаю на моем [предыдущий эксперимент](https://stackoverflow.com/questions/1090911/clearcase-wants-to-merge-unchanged-files-after-deliver-to-alternate-target/1091075#1091075):

 Давайте сделаем новый модификатор в потоке A:

 Доставить это непосредственно в B:

 (Тривиальное слияние)

 Теперь давайте ПОЛНОСТЬЮ ИЗМЕНИМ содержимое этого файла:

 И доставка в Int с новой базовой линией, поставленной сразу после доставки:

 (еще одно тривиальное слияние)

 А как насчет перебазирования от B?

 Вот и все: приятный конфликт между двумя несовместимыми изменениями от общего предка.

 Вот картинка, иллюстрирующая это:

![]()

.



 поскольку ClearCase регистрирует объединение из потока A в B, если только поток B не имеет той же базовой линии (начальная точка для ветви или начальная метка), что и поток A.

 Помимо мероприятия, которое я ему первоначально поставил, ему также предлагается выполнить действие с именем rebase \_..., которое я никогда не ожидал бы предложить для доставки.

 Когда вы переходите от Int к B, вы создаете автоматическую «временную шкалу», которая связывает все действия вместе.  
 Значит, во время следующей доставки B придется доставить ребаз, даже если слияние не будет выполняться для всех версий, представленных в этом наборе изменений.

 Сначала несколько комментариев:

 Вы можете избегать создания потоков, привязанных к ресурсам (разработчик «A», разработчик «B»): если они работают над отдельным набором файлов для одного и того же глобального «процесса разработки», должен быть только один Stream\_FeatureF, представляющий задачу под рукой.  
A и B должны видеть тот же LATEST из той же ветви, присоединенной к этому потоку (нет необходимости доставлять из одного потока в другой)  
 Если B постоянно нарушает работу A, тогда и только тогда можно создать подпоток для разрушительной подфункции, которая не может быть разработана одновременно с основной функцией «F».

 GUI «доставить / перебазировать» не отображает «Да (тривиально)» при слиянии **[Тривиальным](https://www.ibm.com/developerworks/forums/thread.jspa?threadID=142476)** (см. мой тест ниже). Это не означает, что слияние не является тривиальным (это означает, что база совпадает с исходной или целевой, см. **[основные понятия](https://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645771#645771)**)

ест @my, приведенный ниже, учитывает рабочий процесс слияний, которые вы описываете, но показывает только тривиальные слияния.  
 Что могло бы объяснить, что нетривиальные из них будут " **злые близнецы** "(файл, добавленный в один поток, но воссозданный с нуля в другом, с тем же именем)

 Хорошо, давайте проверим это, предполагая Vob "adev" (расшифровывается как "архитектура разработки", где моя команда хранит свои инструменты), с компонентом UCM ADV\_TST в \ adev \ test.  
 ClearCase7.0.1 в Windows (хотя Vob на самом деле работает в Unix)

 Давайте начнем с тестового проекта, одного потока интеграции и одного пустого тестового компонента:

 Давайте сделаем компонент доступным для записи:

A создаст файл в Int, добавит его, изменит его, а затем установит базовую линию:

 Теперь давайте создадим два подпотока, по одному для каждого разработчика (хотя это может считаться «плохой практикой»), оба инициализируются с одинаковым базовым уровнем`TST_DAT1.0.0`:

A внесет изменения в свой поток A, который будет доставлен в B:

 Доставка напрямую из потока А в Б:

 Я подтверждаю, что графический интерфейс не отображался **Trivial** хотя в текстовом выводе того же текста упоминается**`Trivial merge`** ...

 А продолжает работать над '`aFile.txt` 'и доставляет его в Int:

 (Еще одно тривиальное слияние)

 Давайте установим базовый уровень для Int:

 Теперь мы переключаемся на B, который начинает с небольшой работы над другим файлом:

 И тогда ему неожиданно приходится переоценивать свою работу на то, что было объединено в Int:

 **Никаких конфликтов: тривиальные слияния снова**.

B продолжает работать над своим файлом:

 А потом он доставляет всю работу Int:

 Я подтверждаю, что он должен выбрать **все мероприятия** (не только его): временная шкала, установленная во время последней перебазировки, связала все действия вместе.  
 Даже если не будет выполнено слияние с Деятельностью "delivery.Test\_DAT\_A.20090707.123738" и Деятельностью "rebase.Test\_DAT\_B.20090707.125044", они должны быть включены:

.