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

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

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

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

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

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

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

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

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

Заранее спасибо за помощь!

Янв


person Jan    schedule 07.07.2009    source источник
comment
Мне нужно уехать на 2 часа, но я постараюсь сделать тестовый проект UCM и проверить, вижу ли я конфликт в моей конфигурации (CC7.0.1)   -  person VonC    schedule 07.07.2009
comment
Тест добавлен, только тривиальные слияния, конфликтов нет. Посмотрите мои комментарии перед тестом для идей или предложений.   -  person VonC    schedule 07.07.2009
comment
Прежде чем перейти к заключению об ОШИБКЕ, не могли бы вы опубликовать изображение дерева версий файла на freeimagehosting.net (только изображение хостинг, который здесь не заблокирован на работе ...)   -  person VonC    schedule 07.07.2009
comment
Вот он: freeimagehosting.net/uploads/a804fef061.png. Я скорректировал имена веток, чтобы они соответствовали моему примеру. Хронологически последняя стрелка (и та, которая указывает на проблему) - это операция перебазирования из интеграции в поток B.   -  person Jan    schedule 07.07.2009
comment
Да ... Я действительно подтверждаю, что такое слияние (последнее перебазирование до v2 ветки потока B) не должно приводить к конфликту. ClearCase версии 7.0.1 (четверг, 17 мая, 09:19:01 2007) ClearCase версии 7.0.1_iFix01 (среда, 19 сентября, 11:15:35 2007) @ (#) MVFS, версия 7.0.1.0-IFIX01 (среда, 5 сентября, 22:15 : 13 2007)   -  person VonC    schedule 07.07.2009
comment
Подождите, у меня есть идея ... основой для последней перебазировки будет Integration v0, верно? Это означает, что если общая строка изменилась в StreamA и StreamB (из-за первой доставки), то конфликт будет нормальным!   -  person VonC    schedule 07.07.2009
comment
Вернемся к еще большему тестированию (это один насыщенный день;) Мне действительно нужно поддерживать своих постоянных пользователей в ClearCase или SubVersion одновременно;))   -  person VonC    schedule 07.07.2009
comment
Опубликован новый ответ с возможным объяснением конфликтующей перебазировки B   -  person VonC    schedule 07.07.2009
comment
Конфликт достигнут! Тест и иллюстрация размещены в моем втором ответе.   -  person VonC    schedule 07.07.2009
comment
В заключение: неизмененные файлы с точки зрения B, но изменения файлов с точки зрения общего предка. Отсюда конфликт. Ergo ручное разрешение. Интересный побочный эффект бокового слияния (см. ibm.com/developerworks/rational/library /5134.html)   -  person VonC    schedule 07.07.2009


Ответы (2)


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

дерево версий с конфликтом

Когда вы перечитываете способ ClearCase Трехстороннее слияние работает, вы видите, что необходимо вернуться в дереве версий, чтобы найти общего предка для:

  • источник (Int / 2)
  • пункт назначения (B / 1)

Общий предок - Int / 1.

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

  • источник последнего перебазирования (Int / 2) происходит из A / 3
  • место назначения последней перебазировки (B / 1) происходит из A / 2
  • общий предок (Int / 1) происходит от A / 1

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

(Я тестирую это прямо сейчас)


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

Продолжая мой предыдущий эксперимент < / а>:

Давайте сделаем новую модификацию в Stream A:

M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo modif by A to B>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_a\adev\test>type aFile.txt
first line done on Int
Second line from Int
Addition by A to be delivered to B first
Modification by A to be delivered to Int, B does not need it
modif by A to B

Доставим это напрямую B:

M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target Test_DAT_B@\myPVob -cact -gmerge -force
Changes to be DELIVERED to non-default target stream in current project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_A"
          TO: stream "Test_DAT_B"
Using target view: "vonc_test_dat_b".
Activities included in this operation:
        activity:test_dat_a@\myPVob   vonc        "test_dat_a"
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\3" to output file.
Deliver has merged

M:\vonc_test_dat_a\adev\test>ct deliver -target Test_DAT_B@\myPVob -cact -complete -force

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

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

M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo change first line>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_a\adev\test>type aFile.txt
change first line

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

M:\vonc_test_dat_a\adev\test>ct deliver -force
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete
M:\vonc_test_dat_a\adev\test>ct mkbl -comp ADV_TST@\myPVob -view vonc_test_dat_int TST_DAT1.2.0

(еще одно банальное слияние)

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

M:\vonc_test_dat_b\adev\test>ct rebase -bas TST_DAT1.2.0
Advancing to baseline "TST_DAT1.2.0" of component "ADV_TST"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\3".
  Attached activity:
    activity:rebase.Test_DAT_B.20090707.163300@\myPVob  "rebase Test_DAT_B on 07/07/09 4:33:00 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\4 base \main\T
est_DAT_Int\3]
********************************
<<< file 1: M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\3
>>> file 2: M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\4
>>> file 3: M:\vonc_test_dat_b\adev\test\aFile.txt
********************************
---------[changed 1-4 file 1]----------|---------[changed to 1 file 2]---------
first line done on Int                 | change first line
Second line from Int                   |-
Addition by A to be delivered to B fir+|
Modification by A to be delivered to I+|
                                      -|
*** Automatic: Applying CHANGE from file 2 [line 1]
============
============
-----------[after 4 file 1]------------|----------[inserted 5 file 3]----------
                                      -| modif by A to B
                                       |-
Do you want the INSERTION made in file 3?  [yes] no
============
============
Output of merge is in "M:\vonc_test_dat_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.txt".
Build and test are necessary to ensure that any merges and configuration changes were completed correctly.
When build and test are confirmed, run "cleartool rebase -complete".

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

Вот изображение, чтобы проиллюстрировать это:

конфликт во время слияния

.

person VonC    schedule 07.07.2009
comment
Еще раз, большое спасибо за подробное объяснение и все ваши усилия. Жалко, что CC не умнее, потому что технически можно было бы разрешить этот конфликт автоматически. Думаю, для меня это просто означает избегать доставки не по умолчанию. Я думаю, что опасность того, что разработчик в потоке B испортит работу A во время перебазирования, слишком высока. - person Jan; 08.07.2009
comment
Что ж ... это цена, которую нужно заплатить за слияние вбок. Следующее трехстороннее слияние в другой ветке обнаружит изменения в исходном и месте назначения, следовательно, конфликт. На самом деле, мне интересно, будет ли какой-либо другой SCM с поддержкой трехстороннего слияния делать это по-другому? Мне нужно будет проверить это с помощью Git. - person VonC; 08.07.2009
comment
Хороший вопрос. Просто вся информация есть для ClearCase, чтобы определить, какая версия, очевидно, будет правильной после перебазирования. - person Jan; 08.07.2009
comment
Я только что понял, что есть одно решение этой проблемы. Если разработчик B сталкивается с необходимостью слияния во время операции перебазирования, он может отменить перебазирование. Затем разработчик A может выполнить другую доставку в поток B, содержащую те же версии, которые он доставил в поток интеграции. Это снова тривиальное слияние. После этого разработчик B может без проблем выполнить перебазирование. - person Jan; 08.07.2009
comment
@Jan: это действительно одно решение, но если его нужно повторять снова и снова, это также может указывать на то, что текущий рабочий процесс не является оптимальным. Если бы вы могли использовать один поток вместо двух, вам бы не пришлось иметь дело с этими дополнительными слияниями. - person VonC; 08.07.2009

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

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

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


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

  • вы можете захотеть избежать создания потоков, прикрепленных к ресурсам (разработчик «A», разработчик «B»): если они работают над отдельным набором файлов для одного и того же глобального «усилия по разработке», должен быть только один Stream_FeatureF, представляющий задачу в hand.
    A и B должны затем увидеть одно и то же ПОСЛЕДНЕЕ из той же ветки, прикрепленной к этому потоку (нет необходимости доставлять из одного потока в другой).
    Если B постоянно нарушает работу A, тогда и только тогда под- Поток может быть создан для подрывной вспомогательной функции, которая не может быть разработана одновременно с основной функцией "F".

  • В графическом интерфейсе доставки / перебазирования не отображается сообщение «Да (тривиально)», если выполняется слияние тривиально (см. мой тест ниже). Это не означает, что слияние нетривиально (это означает, что база такая же, как источник или место назначения, см. основные концепции)

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


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

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

M:\>ct mkproj -in folder:ADV_Tests@\myPVob Test_DeliverToAlternateTarget@\myPVob
M:\>ct mkstream -int -in Test_DeliverToAlternateTarget@\myPVob Test_DAT_Int@\myPVob
Created stream "Test_DAT_Int".
M:\>ct mkview -tag vonc_test_dat_int -stream Test_DAT_Int@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -bas ADV_TST0.0.0
Adding baseline "ADV_TST0.0.0" of new component "ADV_TST"
M:\vonc_test_dat_int\adev\test>ct rebase -complete

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

M:\vonc_test_dat_int\adev\test>ct chproj -amodcomp component:ADV_TST@\myPVob Test_DeliverToAlternateTarget@\myPVob
M:\vonc_test_dat_int\adev\test>ct chstream -generate Test_DAT_Int@\myPVob
M:\vonc_test_dat_int\adev\test>ct setcs -stream

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

M:\vonc_test_dat_int\adev\test>ct mkact test_dat_int
M:\vonc_test_dat_int\adev\test>echo first line done on Int>aFile.txt
M:\vonc_test_dat_int\adev\test>ct co -nc .
M:\vonc_test_dat_int\adev\test>ct mkelem -nc aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc .
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_int\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_int\adev\test>echo Second line from Int>>aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_int\adev\test>type aFile.txt
first line done on Intct mkview vonc_
Second line from Int

M:\vonc_test_dat_int\adev\test>ct mkbl -comp ADV_TST@\myPVob TST_DAT1.0.0
Created baseline "TST_DAT1.0.0" in component "ADV_TST".

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

M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int@\myPVob Test_DAT_A@\myPVob
M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int@\myPVob Test_DAT_B@\myPVob
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_a -stream Test_DAT_A@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_b -stream Test_DAT_B@\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -complete
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -complete

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

M:\vonc_test_dat_a\adev\test>ct mkact test_dat_a
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
Created branch "Test_DAT_A" from "aFile.txt" version "\main\Test_DAT_Int\2".
M:\vonc_test_dat_a\adev\test>echo Addition by A to be delivered to B first>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

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

M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target Test_DAT_B@\myPVob -cact -gmerge
Changes to be DELIVERED to non-default target stream in current project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_A"
          TO: stream "Test_DAT_B"
Using target view: "vonc_test_dat_b".
Activities included in this operation:
        activity:test_dat_a@\myPVob   vonc        "test_dat_a"
Created branch "Test_DAT_B" from "M:\vonc_test_dat_b\adev\test\aFile.txt" version "\main\Test_DAT_Int\2".
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\0".
  Attached activity:
    activity:deliver.Test_DAT_A.20090707.123738@\myPVob  "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\1 b
ase \main\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\
2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\1" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -target Test_DAT_B@\myPVob -force -complete

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

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

M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo Modification by A to be delivered to Int, B does not need it>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt

M:\vonc_test_dat_a\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_A"
          TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
        activity:test_dat_a@\myPVob   vonc        "test_dat_a"
Do you wish to continue with this deliver operation?  [no] yes
Checked out "M:\vonc_test_dat_int\adev\test\aFile.txt" from version "\main\Test_DAT_Int\2".
  Attached activity:
    activity:deliver.Test_DAT_A.20090707.124108@\myPVob  "deliver Test_DAT_A on 07/07/09 12:41:08 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFile.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\2 base \main
\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFile.txt@@\main\Test_DAT_
Int\2".
Copying "M:\vonc_test_dat_int\adev\test\aFile.txt@@\main\Test_DAT_Int\Test_DAT_A\2" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete

(Еще одно банальное слияние)

Давайте возьмем за основу Int:

M:\vonc_test_dat_a\adev\test>ct mkbl -nc -view vonc_test_dat_int TST_DAT1.1.0
Created baseline "TST_DAT1.1.0" in component "ADV_TST".
Begin incrementally labeling baseline "TST_DAT1.1.0".
Done incrementally labeling baseline "TST_DAT1.1.0".

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

M:\vonc_test_dat_b\adev\test>ct mkact test_dat_b
M:\vonc_test_dat_b\adev\test>echo myFile by B>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct co -nc .
M:\vonc_test_dat_b\adev\test>ct mkelem -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc .

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

M:\vonc_test_dat_b\adev\test>ct rebase -bas TST_DAT1.1.0
Advancing to baseline "TST_DAT1.1.0" of component "ADV_TST"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\1".
  Attached activity:
    activity:rebase.Test_DAT_B.20090707.125044@\myPVob  "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\3 base \main\T
est_DAT_Int\Test_DAT_A\1]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\
Test_DAT_A\1".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt@@\main\Test_DAT_Int\3" to output file.
Output of merge is in "M:\vonc_test_dat_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.txt".

M:\vonc_test_dat_b\adev\test>type aFile.txt
first line done on Int
Second line from Int
Addition by A to be delivered to B first
Modification by A to be delivered to Int, B does not need it

M:\vonc_test_dat_b\adev\test>ct rebase -complete

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

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

M:\vonc_test_dat_b\adev\test>ct setact test_dat_b
M:\vonc_test_dat_b\adev\test>ct co -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>echo a modif by B to be delivered to Int>>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt

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

M:\vonc_test_dat_b\adev\test>ct deliver -cact
cleartool: Error: Activity "deliver.Test_DAT_A.20090707.123738" must be added to activity list to preserve baseline order in stream.
cleartool: Error: Activity "rebase.Test_DAT_B.20090707.125044" must be added to activity list to preserve baseline order in stream.
cleartool: Error: The list of activities specified is incomplete.
cleartool: Error: Unable to deliver selected activities.
cleartool: Error: Unable to deliver stream "Test_DAT_B".

Я подтверждаю, что он должен выбрать все действия (а не только его): временная шкала, установленная во время последней перезагрузки, связала все действия вместе.
Несмотря на то, что слияние не будет выполнено с помощью действия "Доставить". Test_DAT_A.20090707.123738 "и Activity" rebase.Test_DAT_B.20090707.125044 ", они должны быть включены:

M:\vonc_test_dat_b\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
          FROM: stream "Test_DAT_B"
          TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
        activity:deliver.Test_DAT_A.20090707.123738@\myPVob   vonc        "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
        activity:test_dat_b@\myPVob   vonc        "test_dat_b"
        activity:rebase.Test_DAT_B.20090707.125044@\myPVob    vonc        "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Do you wish to continue with this deliver operation?  [no]

  Attached activity:
    activity:deliver.Test_DAT_B.20090707.131614@\myPVob  "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_B\1 base \main\Test_DAT_
Int\1]
********************************
<<< directory 1: M:\vonc_test_dat_int\adev\test@@\main\Test_DAT_Int\1
>>> directory 2: M:\vonc_test_dat_int\adev\test@@\main\Test_DAT_Int\Test_DAT_B\1
>>> directory 3: M:\vonc_test_dat_int\adev\test
********************************
-----------[ directory 1 ]-------------|---------[ added directory 2 ]---------
                                      -| aFileByB.txt  --07-07T12:50 vonc
*** Automatic: Applying ADDITION from directory 2
Recorded merge of "M:\vonc_test_dat_int\adev\test".
Created branch "Test_DAT_Int" from "M:\vonc_test_dat_int\adev\test\aFileByB.txt" version "\main\0".
Checked out "M:\vonc_test_dat_int\adev\test\aFileByB.txt" from version "\main\Test_DAT_Int\0".
  Attached activity:
    activity:deliver.Test_DAT_B.20090707.131614@\myPVob  "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFileByB.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_B\2 base \main\0]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFileByB.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFileByB.txt@@\main\0".

Copying "M:\vonc_test_dat_int\adev\test\aFileByB.txt@@\main\Test_DAT_B\2" to output file.
Deliver has merged
M:\vonc_test_dat_b\adev\test>ct deliver -complete

.

person VonC    schedule 07.07.2009
comment
Интересно, хотя тогда я не понимаю, почему это происходит только в особом сценарии с доставкой в ​​альтернативную цель. Между прочим, потоки A и B используют одну и ту же базовую линию фундамента. - person Jan; 07.07.2009
comment
Прежде всего, огромное спасибо за все усилия и советы. Подводя итог, я понимаю, что я все сделал правильно, хотя, возможно, не рекомендуется использовать два потока, если предполагается, что A и B будут работать вместе. Примечательно, что вы не можете воспроизвести проблемы, которые я могу воспроизвести здесь. Неужели это ошибка в CC? Какую патч-версию клиента вы используете? Или это проблема сервера? - person Jan; 07.07.2009