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

7

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

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

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

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

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

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

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

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

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

Ян

Перед тем как перейти к выводу «ОШИБКА», не могли бы вы опубликовать изображение дерева версий файла на Freeimagehosting.net (только хостинг картинок, который не заблокирован здесь на работе ...) VonC
Мне нужно уйти на 2 часа, но я постараюсь создать тестовый проект UCM и проверить, не вижу ли я конфликт в моей конфигурации (CC7.0.1) VonC
Вот: Freeimagehosting.net / добавление / a804fef061.png. Я скорректировал названия веток в соответствии с моим примером. Хронологически последняя стрелка (и та, которая создает проблему) - это операция ребазирования из интеграции в поток B Jan
Спасибо, это было бы здорово! Jan
Test добавил, только тривиальные слияния, конфликт не возникал. Смотрите мои комментарии перед тестом для идей или предложений. VonC

Ваш Ответ

2   ответа
7

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

Когда ты перечитываешь путьClearCase 3-way merge работает, вы видите, что нужно вернуться в дерево версий, чтобы найти общего предка:

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

Этот общий предок - Int / 1

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

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

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

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

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

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

Давайте сделаем новый модификатор в потоке 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 [email protected]\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:[email protected]\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\[email protected]@\main\Test_DAT_Int\Test_DAT_A\2".
Copying "M:\vonc_test_dat_b\adev\test\[email protected]@\main\Test_DAT_Int\Test_DAT_A\3" to output file.
Deliver has merged

M:\vonc_test_dat_a\adev\test>ct deliver -target [email protected]\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 [email protected]\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:[email protected]\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\[email protected]@\main\Test_DAT_Int\3
>>> file 2: M:\vonc_test_dat_b\adev\test\[email protected]@\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".

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

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

.

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

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

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

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

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

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

GUI «доставить / перебазировать» не отображает «Да (тривиально)» при слиянии Тривиальным (см. мой тест ниже). Это не означает, что слияние не является тривиальным (это означает, что база совпадает с исходной или целевой, см. основные понятия)

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

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

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

M:\>ct mkproj -in folder:[email protected]\myPVob [email protected]\myPVob
M:\>ct mkstream -int -in [email protected]\myPVob [email protected]\myPVob
Created stream "Test_DAT_Int".
M:\>ct mkview -tag vonc_test_dat_int -stream [email protected]\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:[email protected]\myPVob [email protected]\myPVob
M:\vonc_test_dat_int\adev\test>ct chstream -generate [email protected]\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 [email protected]\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 [email protected]\myPVob [email protected]\myPVob
M:\vonc_test_dat_int\adev\test>ct mkstream -in [email protected]\myPVob [email protected]\myPVob
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_a -stream [email protected]\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_b -stream [email protected]\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

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

M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target [email protected]\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:[email protected]\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:[email protected]\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\[email protected]@\main\Test_DAT_Int\
2".
Copying "M:\vonc_test_dat_b\adev\test\[email protected]@\main\Test_DAT_Int\Test_DAT_A\1" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -target [email protected]\myPVob -force -complete

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

А продолжает работать над '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:[email protected]\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:[email protected]\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\[email protected]@\main\Test_DAT_
Int\2".
Copying "M:\vonc_test_dat_int\adev\test\[email protected]@\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:[email protected]\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\[email protected]@\main\Test_DAT_Int\
Test_DAT_A\1".
Copying "M:\vonc_test_dat_b\adev\test\[email protected]@\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".

Я подтверждаю, что он должен выбрать все мероприятия (не только его): временная шкала, установленная во время последней перебазировки, связала все действия вместе.
Даже если не будет выполнено слияние с Деятельностью "delivery.Test_DAT_A.20090707.123738" и Деятельностью "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:[email protected]\myPVob   vonc        "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
        activity:[email protected]\myPVob   vonc        "test_dat_b"
        activity:[email protected]\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:[email protected]\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\[email protected]@\main\Test_DAT_Int\1
>>> directory 2: M:\vonc_test_dat_int\adev\[email protected]@\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:[email protected]\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\[email protected]@\main\0".

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

.

Интересно, хотя тогда я не понимаю, почему это происходит только в специальном сценарии с доставкой к альтернативной цели. Кстати, потоки A и B используют одну базовую базовую линию. Jan
Во-первых, огромное "спасибо" за все усилия и советы. Подводя итог, я понимаю, что все сделал правильно, хотя может быть нецелесообразно использовать два потока, если ожидается, что A и B будут работать вместе. Примечательно, что вы не можете воспроизвести проблемы, которые я могу воспроизвести здесь. Может ли это быть ошибкой в CC? Какую версию патча клиента вы используете? Или это будет проблема с сервером? Jan

Похожие вопросы