Вот довольно сложный вопрос для настоящих экспертов ClearCase:
Я часто выполняю перебазирование в представлении моментального снимка ClearCase, которое имеет очень ограниченное количество небольших изменений в нескольких файлах (например, file1.c, file2.c, file3.c).
Я делаю это следующим образом в командной строке UNIX:
cleartool rebase -recommended -complete
Иногда, когда эта команда выполняется, неожиданно и без объяснения причин (пока) мне предлагается ввести вручную, чтобы разрешить некоторые конфликты «слияния». Но они не имеют для меня никакого смысла, поскольку находятся в файлах, к которым Я НИКОГДА НЕ ПРИКАСАЛАСЬ - и которые ТОЛЬКО ОДИН ДРУГОЙ РАЗРАБОТЧИК КОГДА-ЛИБО ПРИКАСАЕТСЯ.
Подсказки «слияния», которые я вижу, когда этот сценарий происходит во время перебазирования, обычно выглядят так:
"Do you want INSERTION from file x? [yes/no]"
or
"Do you want DELETION from file y? [yes/no]"
or
"Do you want CHANGES from file z? [yes/no]".
Etc.
Я понятия не имею, почему происходят эти «конфликты». Кроме того, действительно сложно (увидеть невозможное) принимать правильные решения, потому что детали показаны в очень узком количестве столбцов, и вряд ли есть какой-либо способ правильно угадать. Использование графического слияния здесь не вариант, потому что оно предназначено для сценария автоматизации, который в идеале никогда не должен запрашивать ввод пользователя.
Что я знаю об этом сценарии:
У нас есть команда из 6 разработчиков. Пятеро из нас обычно работают с одним и тем же ограниченным количеством файлов ... скажем, file1.c, file2.c, file.3.c
Я работаю над потоком развития детей над этими тремя файлами. И когда я закончу, я обычно доставляю до родительского потока по умолчанию.
В тех случаях, когда возникали «конфликты слияния» при перебазировании, он всегда находился в совершенно ДРУГИМ ФАЙЛЕ - к которому ВСЕГДА ТРАГАН ТОЛЬКО ОДИН другой разработчик в команде (это модуль, которым ОН владеет, НИКОГДА НИКОГДА КАСАЕТСЯ ФАЙЛА, НО НЕГО). Назовем его разработчиком №6.
Когда случается этот странный «конфликт слияния» при перебазировании, я обычно продолжительное время работал в собственном дочернем потоке разработки (всегда с представлением моментального снимка), и я сделал пару перебазов (как минимум 3), чтобы другие изменения, ВСЕ сделанные другими разработчиками (в file1.c, file2.c и file3.c) и которые мне понадобились для завершения моей работы.
Но другой разработчик (№6), ТОЛЬКО ОДИН, работающий над banana.c, внес изменения в этот файл по крайней мере в двух из трех действий по перебазированию, которые были созданы в представлении моментальных снимков поток развития моего ребенка.
Опять же, повторяю, я НИКОГДА не трогал banana.c, и никто из 5 других разработчиков никогда этого не делал, за исключением парня (№6), который владеет модулем banana.c.
И там это произошло - ClearCase попросил меня ввести вручную, чтобы разрешить конфликт «слияния» с banana.c при выполнении «cleartool rebase -recommended -complete».
Как это может быть возможным???
Как может файл требовать «слияния» при выполнении перебазирования, если ТОЛЬКО один разработчик вносит в него изменения?
Это как если бы ClearCase запутался между разными версиями banana.c по крайней мере в двух из трех действий перебазирования, автоматически созданных в моем потоке (которые оба изменяли banana.c), и предлагал мне разрешить «конфликт слияния» (хотя я никогда не коснулся banana.c, и только один разработчик (№6) когда-либо изменил этот файл).
. . .
ОБНОВЛЕНИЕ: 31 АВГУСТА 2015 ГОДА
Вот протокол возникновения проблемы 28 августа 2015 г.
Needs Merge "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp" to /main/MAIN_INT_STREAM/SUB_STREAM/CHECKEDOUT from /main/MAIN_INT_STREAM/SUB_STREAM/MY_DEV_STREAM/37 base /main/
MAIN_INT_STREAM/SUB_STREAM/150
********************************
<<< file 1: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp@@/main/MYDYNAMICVIEW/SUB_STREAM/150
>>> file 2: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp@@/main/MYDYNAMICVIEW/SUB_STREAM/MY_DEV_STREAM/37
>>> file 3: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp
********************************
...CUT FOR BREVITY...
*** Automatic: Applying DELETION from file 3 [deleting base line 123]
...CUT FOR BREVITY...
*** Automatic: Applying INSERT from file 3 [lines 123-124]
...CUT FOR BREVITY...
*** Automatic: Applying CHANGE from file 3 [lines 1329-1335]
...CUT FOR BREVITY...
*** No Automatic Decision Possible
merge: Warning: *** Aborting...
Missing charsets in String to FontSet conversion
Missing charsets in String to FontSet conversion
Missing charsets in String to FontSet conversion
Cannot convert string "-misc-kochi mincho-medium-r-normal--0-*-*-*-*-*-*-*" to type FontSet
...GMERGE POPPED HERE...
Moved contributor "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp" to "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp.contrib".
Output of merge is in "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp".
Recorded merge of "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp".
Я никогда не касался SOMEFILE.cpp - только ОДИН другой разработчик когда-либо менял - почему это требует слияния?
На данный момент у меня сложилось чистое впечатление, что автоматическое слияние ClearCase выполняет плохая работа.
Может быть, было бы неплохо подумать об использовании параметров "-qall" или "-qntrivial", чтобы отключить автоматическое слияние ВСЕХ / БОЛЬШИНСТВ - и выполнить слияние ВСЕ / БОЛЬШИНСТВО вручную? (или с помощью внешнего инструмента?)
