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

У меня есть 3 проекта A, B на основе A, C на основе A.

Изменения A следует сначала объединить с B, а затем с B на C. Также есть изменения в B, не влияющие на A, но некоторые из этих изменений необходимо объединить в C.

Есть некоторые изменения из A, которые были неправильно объединены непосредственно из A в C, минуя B. (Я использую слово «объединено», потому что нам нужно было объединить их вручную, потому что автоматическая доставка включала бы кучу действий, которые нам не нужны. доставить в B и C).

Чтобы решить проблему, мне теперь нужно объединить изменения, которые не были объединены в B, но были объединены в C в B, и я ищу способ перечислить все версии в C, которые были созданы путем слияния из A, поэтому что я могу объединить изменения для этих файлов в B.

Спасибо


clearcase clearcase-ucm
person axk    schedule 08.07.2009    source источник
comment
добавьте некоторые соображения по команде findmerge, как просили.   -  person VonC    schedule 09.07.2009
comment
Добавлен комментарий к findmerge, как и просили. См. также publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/ для справки.   -  person VonC    schedule 09.07.2009

Ответы (1)


arrow_upward
2
arrow_downward

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

Эти версии должны быть перечислены в действии слияния, которое вы должны создать при слиянии непосредственно из A в C (я полагаю, используя findmerge).

Единственная проблема заключается в том, что вы создали специальное действие "слияния" во время этого findmerge?
Возможно, вы просто повторно использовали текущее действие на C, а это означает, что действие будет содержать версии из текущей работы на C, а также версии, объединенные из А.

Другой подход заключается в слиянии одних и тех же действий (тех, которые связаны с поиском слияния от A к C) от A к B.
Следующее «нормальное» слияние от B к C будет:

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

Я не использовал его для этих слияний, сделал это из инструмента дерева версий графического интерфейса, создав идентичные действия в C для соответствующих действий в A и объединив файл за файлом.

Если у вас нет только одного или двух файлов для слияния, findmerge — это команда, которую следует использовать, потому что:

  • он может учитывать одно или несколько действий
  • и он не связан теми же «зависимостями действий», которые применяются с помощью операции доставки или перебазирования UCM.

Короче говоря, findmerge — это классическое слияние, способное считывать версии в действиях UCM, но выполняющее слияние, отличное от UCM (без гиперссылки между базовыми показателями UCM).

person VonC    schedule 08.07.2009
comment
Спасибо! Эта команда findmerge решает проблему, указанную в вопросе, а также отлично экономит время для выборочных операций слияния, которые невозможно выполнить с доставкой UCM! - person axk; 09.07.2009
comment
Еще один вопрос: как findmerge определяет, какие версии объединять? Является ли это простой операцией сравнения последних версий в исходной ветке с текущими версиями тех же элементов в целевом представлении или это что-то более сложное, связанное с отношениями версий? Возможно ли, что он потребует слияния двух идентичных версий (один и тот же элемент с одинаковым содержимым)? Спасибо! - person axk; 09.07.2009
comment
если вы используете findmerge с опцией fcset, вы укажете название деятельности. findmerge будет использовать только точные версии, перечисленные в каждом действии. См. также www-01.ibm.com/support/docview. wss?uid=swg27012941&aid=2 - person VonC; 09.07.2009