Merge output not always showing highlights

[davenovak]

Hello --

I'm not sure if this is my misunderstanding of 3-way (or even 2-way) text merge, or an actual bug. But here's the situation: I often don't see any highlighting when merge output successfully merges in a change. Take this example from the attached picture:



Now, from my perspective, the output window should show this change in light purple, since it is a change -- coming from the right file -- to the original ancestor file. Instead, the vertical change bar (to the left of the output window) and the merge background color are both plain white (which, to me, indicates no change). Changes on the left seem to always show up in light blue (as expected).

If this is not a bug, what am I missing here? Please explain.

Thanks,

--Dave Novak

[Aaron]

Do you have Favor Left or right enabled? That would explain the coloring, but not the lack of section bars. Can you reproduce this?

Could you send us a copy of the files and your Support.zip (Help menu -> Support; Export) to [email protected] ? Please include a link to this forum post as well, so we can link the email to the forum post.

[davenovak]

It didn't seem to matter whether Favor Left/Right was selected. And yes, I can reproduce this easily. I'll send you some example files later today.

Thanks!

--Dave Novak

[Aaron]

Thanks.

Please include a link back to this forum post, and your Support package as well. Thanks, again.

[davenovak]

My bad -- I stated it didn't make a difference if either Favor Left or right was enabled. That's not the case. If Favor Left (or no Favor) is specified, it "works" as intended; Favor Right is the only case where I see problems.

Will send you some files shortly.

Thanks!

[davenovak]

I tried emailing these files, but kept getting rejections due to alleged virus (possibly because of included .BAT file and .LUA scripts). In any case, I'm attaching these here as it appears to be the only way for me to get these to you.

Again, please note that the problem only seems to show up when using the /favorright option.

Thanks,

--Dave

[Aaron]

Hello,

If you favor right, and a right change is taken automatically (it is taken regardless of if Favor Right is set; it is not a conflict), then we don't color those changes. The Help Text on the FavorRight command line:

Non-conflicting changes from "favored" side are drawn without coloring
or section lines in the merge output, and ignored unimportant conflicts
automatically take changes from that side instead of the center.

The purpose is to then allow easy review of changes taken from the other sides, but changes that were automatically taken from the Right side do not need to be reviewed. Similar to the Ignore Unimportant toggle, to skip over Unimportant differences. Does that help clarify what is happening?

[davenovak]

That helps a little . . . especially the analogy with Ignore Unimportant. Having said that though, it's only fair that I point out that Ignore Unimportant is, in fact, a toggle that the user controls. And for me, I would love to be able to toggle whether or not these non-conflicting changes from "favored" side are drawn. If that feature existed, I would be happy.

I have to admit though that I still don't understand is why these changes are not highlighted by default. I guess I just don't fully understand (or agree with) the current design. From my perspective, given that 3-way merge already makes a distinction between a conflict and a difference (and even has next/previous conflict and difference buttons), why aren't all differences highlighted in the output? Having said that though, I'd be perfectly content if I could merely toggle the highlighting of these non-conflicting changes from "favored" side.

In the meantime, do you have any suggestions for helping me review these merges? Specifically, what's the impact of not specifying either /favorleft or /favorright? What's the default behavior? Perhaps I can just drop /favorright?

[Zoë]

The default is no /favor, in which case it always draws all differences from both sides. If you don't like the behavior you're seeing just stop passing the switch.

The /favor switches were added to help when you're performing a second merge. Eg, the D+E->F merge here:

A
| \
B  C
| \|
D  E
  \|
   F

If I remember correctly, it was added at the request of the Code Co-op guys (a distributed VCS), and they always pass one of them in. We don't recommend it in general, and none of the command lines in our VCS knowledge base article include either of those switches.

[Aaron]

In addition to Craig's comments, the Favor commands are toggles. They are under the View menu, or can be added to the Toolbar with the Tools menu -> Customize Commands. But as Craig mentions, you probably don't want to use them unless you explicitly know you want to hide the color. Turning it on does not change which text is taken (unless it is an Unimportant Conflict); the primary purpose to to help code review: hiding the color so you don't have to see it.

[davenovak]

So when using either of the /favor switches, the difference is only visual? The difference is only that "Non-conflicting changes from "favored" side are drawn without coloring or section lines in the merge output . . . "?

If that's the only difference, then there already is a toggle for this behavior and I (inadvertently) have said "no I don't want you to show me these non-conflicting changes". Is this this case?

Please clarify.

[Aaron]

Graphically, the toggles are located under the View menu. You can toggle on or off (default off): Favor Left or Favor Right. This hides the color on that side in the output, since it assumes you don't want to review it, because you favor it (and there was no conflict stopping you from taking it automatically).

By providing the /FavorRight command on the command line, you are toggling this option on.

Side Note: The difference is not only visual, but mostly visual. If you have a Conflict, normally the user must resolve it. If this conflict is made up entire of Unimportant differences (blue), then the FavorRight command will take the right side. If there is any red, however, it will remain a conflict and need to be resolved manually.

[Aaron]

Try turning the option off (not using /favorright) and using the default behavior. Does that behave as you expect?

[davenovak]

You explanations have been very helpful and I now fully understand what the /favor switches do.

For me, I will be just fine by not specifying any /favor and simple going with the default (even if that means more conflicts). And thanks for pointing out those toggle options on the View menu. I'm so used to using the toolbar button and right-mouse context support that I rarely even use the menus.

Bottom line: BC3 is/was doing exactly what it's supposed to do and the user has full control over the /favor options from the View menu. Therefore, I have everything I need at my disposal and will simply drop my usage of /favorright.

Thanks for you help and patient explanations.

--Dave Novak