I need to force a merge even if there are conflicts

[Michael Bulgrien]

Sorry, re-reading the thread I realize I was mistaken about what you're asking for. The workaround I proposed (which isn't what you tried) should end up with a compilable version, but it won't be the same as if loading it interactively and saving it.

In my last post I metioned that I was withdrawing my enhancement request because I realized that it would not be as simple to implement as I first expected. My initial request was based on some assumptions. I assumed that BC3 already used the /favorright and /favorleft parameters to assist in resolving conflicts both during an interactive merge and an automerge. I guess I was wrong. I am not sure what /favorright and /favorleft really do. It seems to me that they are less useful then they could be.

Suffice it to say that forcing a save without conflict markers would only be valuable if /favorright and /favorleft are honored. In other words, my proposed /noconflictmarkers option should only be permitted if a user also specified what side to favor. Then BC3 should automatically resolve any conflicts to the favored side and save the merge file without conflict markers. If a /favorright or /favorleft parameter is not specified, a /noconflictmarkers paramerer would need to be ignored.

Implemented any other way, a /noconflictmarkers parameter woud be useless. You can add the /noconflictmarkers idea to the wish list...but only if BC3 resolves conflicts from the favored side during the forced automerge.

Thanks again for your patience with me as I explored the automerge capability. I've already assessed that I can programmatically manipulate the forced merge output to my needs (I am aware that I can programmatically preserve the favored side after capturing the error code 14). That will serve my needs for the present.

[Zoë]

/favorright and /favorleft affect coloring in the output. In non-conflicting sections the favored side is drawn with the normal "no change" coloring and the next difference commands don't stop at those sections. We originally added it for Code Co-op; when it calls us for merges it passes the previous revision in as the base instead of a common ancestor, so they only want to emphasis changes that occurred in the most recent revision.

To get back to your request: Currently when showing interactive merges with conflicts, BC pulls changes from each side on a line-by-line basis, and defaults to the center for lines with differences on all three sides. This works well for trivial "conflicts" where it's just a conflict because two changes are next to each other. It sounds like in your case you want it to take the favored side for the entire conflict, correct? If that's the case that's something we could do for /automerge /force /favorxxx.

[Michael Bulgrien]

Yes, that was my thought...to take the entire conflict based on the favored side. Obviously, the scope of the conflict would be defined by the Session Settings Alignment tab.