ClearCase合并后在基础上发生冲突的奥秘-为什么在对没有本地更改的文件进行重新设置时有时需要手动合并？ [英] ClearCase merge-conflict-on-rebase mystery -- why does manual merges are sometimes required when doing a rebase for a file that has NO local changes?
问题描述
对于真正的ClearCase专家来说，这是一个相当高级的问题：
我经常在ClearCase快照视图上执行重新存储，该快照视图中仅有很少的小变化文件（例如file1.c，file2.c，file3.c）。
我在UNIX命令行上执行以下操作：
cleartool rebase-推荐-complete
有时，当此命令运行时，突然出现尚无任何原因（目前），我得到提示以手动输入方式解决一些合并冲突。但是它们对我来说是没有意义的，因为它们发生在我从没有碰过的文件中-并且只有一个其他开发者从未接触过的文件。
我看到合并提示在重新定型期间发生这种情况的时间通常如下：
是否要从文件x插入？[是/否]
或
您是否要从文件y插入？[是/否]
或
是否要从文件z更改？[是/否]。
等
我不知道为什么发生这些冲突。另外，很难做出正确的决定（看不到），因为详细信息的显示列非常少，几乎没有办法猜对。在这里不能选择使用图形合并，因为这意味着自动化脚本在理想情况下应该永远不要求用户输入。
我对这种情况了解的是：
我们有一个由6个开发人员组成的团队。我们中有5个人通常使用相同数量的文件...比如说file1.c，file2.c，file.3.c
我在儿童发展流中工作在这三个文件上。完成后，我通常会提供默认的父流。
在重新设置基础上发生合并冲突的情况下，总是总会发生不同的文件-团队中只有另一个开发人员曾经碰过过的文件（这是他拥有的模块，没有人碰到过文件但他发了短信）。让我们称他为开发人员＃6。
当在重新设置基础上发生这种奇怪的合并冲突时，我通常在自己的开发子流中工作了很长时间（总是带有快照视图），并且我做了一些修改（至少3个）以带来其他开发人员（在file1.c，file2.c和file3.c中）所做的所有其他更改，而我需要完成这些更改工作。
但是，另一个开发人员（＃6），正在处理banana.c的 ONLY ONE ，对该文件进行了更改，位于在子开发流的快照视图中创建的三个变基活动中至少有两个。
同样，我重复一次，我从没碰过banana.c，没有一个除了拥有banana.c模块的那个家伙（＃6）之外，其他5个开发人员都曾经做到过。
然后，发生了-ClearCase要求我进行手动输入在执行 cleartool rebase -recommended -complete时解决与banana.c的合并冲突。
-
这怎么办
-
如果只有一个开发人员进行更改，那么在进行重新设置时文件如何要求合并？
-
在我的流中自动创建的三个变基活动中，至少有两个是ClearCase似乎在banana.c的不同版本之间感到困惑（都修改了banana.c）并提示我或合并冲突解决方案（即使我从未接触过banana.c，并且只有一位开发人员（＃6）曾经修改过该文件）。
。
。
。
更新：2015年8月31日
以下是2015年8月28日问题发生的日志
需要合并 / view / MYDYNAMICVIEW / vobs / DIRLEVEL1 / DIRLEVEL2 / SOMEFILE.cpp从/ main / MAIN_INT_STREAM / SUB_STREAM / MY_DEV_STREAM / 37 base / main /
MAIN_INT_STREAM / SUB_STREAM / 150
*******至/ main / MAIN_INT_STREAM / SUB_STREAM / CHECKEDOUT *************************
<<<文件1：/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp @@ / main / MYDYNAMICVIEW / SUB_STREAM / 150
>>文件2：/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp @@ / main / MYDYNAMICVIEW / SUB_STREAM / MY_DEV_STREAM / 37
>>>文件3：/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp
***************************** ***
...简化功能...
***自动：从文件3应用DELETION [删除基线123]
...简化功能...
***自动：从文件3中应用INSERT [行123-124]
...为简便而剪切...
***自动：从文件3中应用更改[行1329- 1335]
...为求精简...
***无法自动决策
合并：警告：***中止...
缺少字符串中的字符集FontSet转换
缺少字符串中的字符集到FontSet转换
缺少字符串中的字符集到FontSet转换
无法转换字符串 -misc-kochi mincho-medium-r-normal--0-*-* -*-*-*-*-*键入FontSet
...在此处合并...
已将贡献者 /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp移至 /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp.contrib 。
合并的输出在 /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp中。
记录的 /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp的合并。
我从没碰过 SOMEFILE.cpp -只有一个开发人员更改过-为什么需要进行合并？
目前，我的净印象是ClearCase的自动合并做得不好。
可以考虑使用 -qall 或 -qntrivial 选项可禁用ALL / MOST自动合并-并手动进行EVERY / MOST合并吗？ （或使用外部工具？）
1& 2这怎么可能？???
这条您是否希望在文件2中进行更改？[是]否消息仅在）会更好。
关于2015年8月的更新，关键错误消息是：
缺少字符串到FontSet转换中的字符集
请参阅技术说明 使用GUI导致字符串到FontSet转换中缺少字符集警告
可能的原因包括：
- 语言环境变量的设置不正确。例如，可以将其设置为UTF-8。
- 感兴趣的文件是Linux / palette，它定义了环境中使用的实际字体。读取该文件以确定可以在ClearCase GUI中显示的字体。
- 调色板文件不包含正确的字体集。
此问题被识别为产品缺陷，并记录在APAR PK30799下。
Here's a rather advanced question for true ClearCase experts:
I frequently perform a rebase on a ClearCase snapshot view that has just a very limited number of small changes in few files (e.g. file1.c, file2.c, file3.c).
I do it with the following on the UNIX command line:
cleartool rebase -recommended -complete
Sometimes, while this command runs, out of the blue, and for no exlained reasons (yet), I get prompted for manual input to solve some "merge" conflicts. But they make no sense to me, as they happen in file(s) that I NEVER EVER TOUCHED -- and which ONLY ONE OTHER DEVELOPER EVER TOUCHES.
The "merge" prompts I see when this scenario happens during a rebase look usually like:
"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.
I have no clue why these "conflicts" are happening. Additionally, it's really hard (see impossible) to make good decisions because the details are shown with a very narrow number of columns, and there's hardly any way to guess right. Using graphical merging is not an option here because this is meant for an automation script that should ideally never ask for user input.
What I do know about this scenario is:
We have a team of 6 developers. 5 of us usually work the same limited number of files... say file1.c, file2.c, file.3.c
I work on a child development stream on these three files. And when I'm done, I normally deliver up to the default parent stream.
On the occasions where the "merge conflicts" on rebase happened, it's always on a totally DIFFERENT FILE -- one that is ONLY EVER TOUCHED by JUST ONE other developer in the team (it's a module that HE owns, NO ONE EVER TOUCHES THAT FILE BUT HIM). Let's call him developer #6.
When this strange "merge conflict" on rebase happens, I've usually been working for an extended time in my own development child stream (always with a snapshot view), and I've done a couple rebases (at least 3) to bring other changes ALL made by other developers (in file1.c, file2.c and file3.c) and which I needed to complete my work.
But, the other developer (#6), the ONLY ONE working on banana.c, had made changes to that file, in at least two of the three rebases activities that were created in the snapshot view of my child development stream.
Again, I repeat, I NEVER touched banana.c, and none of the 5 other developers ever did, except for the guy (#6) who owns the banana.c module.
And there, it happened - ClearCase asked me for manual input to solve a "merge" conflict with banana.c when doing "cleartool rebase -recommended -complete".
How can this be possible???
How can a file require "merging" when doing rebase if there is ONLY EVER one single developer making changes to it?
It's as if ClearCase got confused between different versions of banana.c in at least two of the three rebase activities automatically created in my stream (which both modified banana.c) and prompted me for "merge conflict" resolution (even though I never ever touched banana.c and only one developer (#6) ever did modify that file).
. . .
UPDATE: AUGUST 31ST 2015
Here's a log from an occurrence of the problem on August 28th 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".
I never touched SOMEFILE.cpp - only ONE other developer ever changes it- why does it require a merge?
My net impression at the moment is that ClearCase's automatic merge is doing a bad job.
Could it be a good idea to think of using the "-qall" or "-qntrivial" options to disable ALL/MOST automatic merging -- and do EVERY/MOST merge manually? (or with an external tool?)
1 & 2 How can this be possible???
This "Do you want the CHANGE made in file 2? [yes] no" message only appears when 2 contributors differ from the base contributor.
In that case, a cleartool lsvtree (not with -graph, since you don't have X-Window server) might help seeing the version involved, and trying to make some cleartool diff to see the difference (compared to the base contributor)
3/: that is one example where, if possible, working collaboratively on the same stream/branch (instead of working each developer in one own's stream) would be better.
Regarding the update of August 2015, the key error message is:
Missing charsets in String to FontSet conversion
See technote "Using GUI results in "Missing charsets in String to FontSet conversion" warning"
Possible causes include:
- An improper setting of the locale variable. For example it may be set to UTF-8.
- The file of interest is the Linux/palette, which defines the actual fonts used in the environment. This file is read to determine the fonts that can be displayed in the ClearCase GUI.
- The palette file does not contain the correct fontset.
This issue was identified as a product defect and logged under APAR PK30799.
这篇关于ClearCase合并后在基础上发生冲突的奥秘-为什么在对没有本地更改的文件进行重新设置时有时需要手动合并？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
