1

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".

  1. How can this be possible???

  2. How can a file require "merging" when doing rebase if there is ONLY EVER one single developer making changes to it?

  3. 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?)

user972301
  • 137
  • 8
  • I've had a look at this which seems to describe a somewhat-similar scenario: http://dbaspot.com/configuration-management/193328-clearcase-rebase-merge-why-2.html ---- we normally have everyone manually create/recommend a baseline after each and every delivery ---- but it depends on humans remembering to do the manual steps every time ---- I wonder if what I've encountered with "cleartool rebase -recommended -complete" wouldn't be related to the other #6 dev having forgotten to create/recommend a baseline? – user972301 Mar 07 '15 at 05:47

1 Answers1

0

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)

https://stackoverflow.com/a/9534815/6309

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the great explanations VonC, this is extremely appreciated. However please note that the prompts I quoted may not be exactly accurate -- I'm just mentioning from memory, as I had not captured a log of the messages I got when it happened. So the prompts might not be exactly what's happened. But I know that the file had been changed just by dev #6. I remember the baselines that caused this to happen this week, so I might have a chance to reproduce the exact same problem using a stream created with the same old baseline and rebase it. I'll give it a try today and capture a log. – user972301 Mar 07 '15 at 17:59
  • @user972301 still, I would still consider as a good practice to work on the same stream. – VonC Mar 07 '15 at 18:02
  • Unfortunately I could not reproduce. Tried to create stream with old baseline, rebase a few times going closer to the present date gradually -- but it never triggered the merge. I will have to wait until this happens again. About working on similar stream, it appears that people are used to separate streams here, so I have no control over that unfortunately... Thanks for the help so far. When this shows up again I'll capture a log. – user972301 Mar 07 '15 at 21:57
  • I got very lucky today and reproduced the exact same merge issue while I had to do yet another rebase on my child stream's view which hasn't done any delivery in over a month. The files that conflicted have NOT been changed by me, and yet they cause merge conflicts. I seriously expect that at least two of the rebase activities currently sitting in the view are somehow conflicting with the new code of the recommended baseline which might be modifying the same files that I haven't touched myself. – user972301 Mar 10 '15 at 00:46
  • The answer above still doesn't explain why two contributors, who are working on remote machines, might still be causing a merge locally on my own machine when they have modified files that I haven't and when my view is completely clean (with no local changes). I suspect that somehow the multiple rebase activities accumulated are conflicting with someone else's changes, and I find it ridiculous that I might have to merge other people's code if it cannot locally be conflicting with mine. – user972301 Mar 11 '15 at 01:06
  • @user972301 the answer above is just a pointer as to where to look and what diff to do between which version in order to gain a more precise understanding of why there is a conflict. – VonC Mar 11 '15 at 07:38
  • Okay - fair enough - but when exactly should I try `cleartool lsvtree` and `cleartool diff`? (If the mysterious merge conflict is happening during a rebase done with an automated script with `cleartool rebase -recommended -complete [-gmerge]`, there is no prompt available to run these commands. Can I just open another unix console terminal and do that in parallel in the same snapshot view when merge conflicts happen? (I assume yes...)). – user972301 Mar 14 '15 at 02:39
  • @user972301 That is why I don't use the `-complete` right away: that means I can diff after the first merge step, which can ends with conflicts. Actually, in that case, I relaunch the merge through the GUI, in order to make the diffs that way. – VonC Mar 14 '15 at 10:57
  • Unfortunately I could not spare enough time to re-test this, as I had to complete work that was due. However with the knowledge I've gained so far on this, I'm fairly certain that I might be able to reproduce it if I just create a development child stream and an associated snapshot view and never really change any files in it -- but just keep rebasing every day or every week for a while. Eventually the rebase activities will pile up on that stream and changes they contain coming from OTHER developers will start to conflict with each other and trigger merge conflicts on rebase. – user972301 Mar 18 '15 at 00:32
  • It took a number of months before this happened again, but now I managed to catch this issue happening again. I've captured a log. I will likely need some space to paste here. But basically, I've witnessed two failures of automatic merging, which caused the graphical-based merge to pop-up. AGAIN NOTE: The files I am being asked to merge have NOT been changed by ANYONE but "developer #6". NOBODY ELSE IN THE TEAM HAS TOUCHED IT - SO WHY MERGE NEEDED? – user972301 Aug 31 '15 at 14:18
  • Stackoverflow is wrongfully complaining about some formatting issue in my updated post and I am unable to post right now and I have to go to a meeting -- will retry again to update later. – user972301 Aug 31 '15 at 14:30
  • Ok - managed to fix identing issues -- it took many edits but I updated the question above with latest details I have. – user972301 Aug 31 '15 at 15:19
  • Thanks -- really appreciated. I skimmed quickly and it sounds like you might be on to something. Will give a detailed look as soon as time allows this week. I'm glad I've started to capture these cleartool logs now! :) – user972301 Aug 31 '15 at 17:21
  • Well... after reading a little bit I tend to disagree about the charset issue (for now) -- looking closely at the logs, the first error that occurred shows up BEFORE the GUI is popped up, while automated merging is happening in text mode: `*** No Automatic Decision Possible merge: Warning: *** Aborting...` -- so I'm not sure the current lead to troubleshoot issues with fonts in the GUI is accurate. What is this "No Automatic Decision Possible" message relating to? Could it rather be some UTF-8 characters in source files preventing merging? Let me know what you think. – user972301 Aug 31 '15 at 19:35
  • @user972301 What ClearCase version are you using? What the OS is on the server? on the clients? – VonC Aug 31 '15 at 19:36
  • Doing a `cleartool -ver` gives me lots of output that is too big to paste here -- but ALL the version numbers shown begin with 8.0.0.X. – user972301 Aug 31 '15 at 19:38
  • On the client side where I am seeing this I have Ubuntu 12.04 LTS `Linux ca628928 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux` -- how can I find about the server OS? – user972301 Aug 31 '15 at 20:01
  • @user972301 your ClearCase admin will know that (or the clearcase logs might mention it). I don't have more elements at the moment. I'll see what I can find tomorrow. – VonC Aug 31 '15 at 20:03
  • I'm trying to avoid bugging the CC admin if possible, so I tried to fetch the information myself using `cleartool hostinfo -long`. I found my "registry server", and queried again with the same command. According to the output I get the server is running CC 8.0.1.4 on HP-UX B.11.31 U, on ia64. – user972301 Sep 01 '15 at 16:48
  • I am still trying to wrap my head around this problem. Now taking into account that the messages displayed are `*** Automatic: Applying CHANGE from file 3 [lines 1329-1335] ...CUT FOR BREVITY... *** No Automatic Decision Possible merge: Warning: *** Aborting...`, I think you might need to edit your answer as it appears we are going on a different path (the issue seems to be with some failing Automatic Merge)... I'd like to understand why, and also maybe what are the steps done by `cleartool rebase ...` as far as merging is concerned, to see if I could zero in on something. – user972301 Sep 03 '15 at 00:55
  • I know that the file in question was edited several times by JUST THE SAME PERSON, and he had several "rebase" activities in his view since he was asked not to deliver for a while. When he finally delivered his stuff, that one file, only edited by him, got ClearCase to prompt us for merging while we happened to do rebases on our side after his delivery. I *think* when this showed up for me I also had several "rebase" activities piled up in my snapshot view. Somehow I think I might have older versions of the file in at least one of these piled up "rebase" activities. Could that cause it? – user972301 Sep 03 '15 at 00:57
  • @user972301 yes, it could: any concurrent modification in both branches merges (here an UCM rebase, from a parent stream to a child stream) can cause a conflict. – VonC Sep 03 '15 at 09:05
  • Ohhh... OK -- Let's see if I got you right: if *THE SAME REMOTE PERSON* modifies a file in his child development stream, then delivers his changes to a common parent integration stream, and during that time I'm working in a child dev stream under that same parent integration stream and I rebase while already having one (or more) older versions of that same file, in a previous rebase activity in my own dev stream (still only from the *SAME PERSON*) to pick up his latest changes, it will cause a conflict in my child development stream? (sounds like it is what happens constantly to us here). – user972301 Sep 04 '15 at 13:23
  • @user972301 yes, this isn't some much about the "same person" aspect, and more about the *concurrent* modifications which will trigger conflicts. – VonC Sep 04 '15 at 13:33
  • Aha... I have heard of an "evil twin" issue with ClearCase - is that related to this in any shape or form ? Anyhow, sounds like there's no way around this... :( – user972301 Sep 05 '15 at 18:08
  • @user972301 only if the same element is added to source control twice in different branches: http://stackoverflow.com/q/13283401/6309, http://stackoverflow.com/q/11705061/6309, http://stackoverflow.com/a/27635705/6309 – VonC Sep 05 '15 at 18:12
  • Ok, so this issue isn't the evil twins one because the files are never added/removed from the different streams, they are only modified. We've recently had enough of these pointless merges, and after a long planning, finally decided to move to using GIT... so that problem shouldn't be affecting us anymore. I would have wished I could have a clear way to reproduce it to explain it though. – user972301 Oct 08 '15 at 01:56
  • @user972301 great choice. I know Git well, and I will be able to help. – VonC Oct 08 '15 at 04:32