I need to force a merge even if there are conflicts

[Michael Bulgrien]

I need to force a 3-way merge output file to be saved even if there are conflicts. The help file says:

/force Forces /automerge to create an output file with CVS-style conflict markers if conflicts are found.

However, I definitely do not want conflict markers saved in the file. I want BC3 to favor the side I specify and just save the output file. If you must alter the output file due to the conflicts, then I want a single line added to the very top of the file indicating that there were conflicts during the merge, but no markers inserted within the body of the file itself.

I am working through a project in which I am merging over 1800 files. I have follow up tools to verify whether or not a merge was successful, and the presence of conflict markers would impact the validation (because the conflict markers would be detected as invalid code).

[Zoë]

It should be prety easy to do this from VBScript; just wrap the call to BC, check the exit code, and if it's a conflict do a search&replace on the conflict markers. This doesn't sound like a bad suggestion, but I can't see us adding yet more automerge flags without additional requests for it.

[Michael Bulgrien]

When I call BC3 from a vbScript using the Windows Scripting Host shell.run command, error codes do not seem to be returned. Is there a better way to run BC3 from within a vbScript that will capture the errors?

[Zoë]

According to MSDN, shell.Run has an optional third parameter controlling whether to wait for the process, and if it's true the return value is the program's exit code. There's sample code at the link.

[Michael Bulgrien]

Well, now, that kind of defeats the purpose, don't you think? I run a batch of compares, have them launch in separate tabs in BC3, then work through the sessions. I couldn't do that if I set the wait parameter to True, now could I? Working on each compare one at a time before the process continues would certainly impact my productivity. Hence my request for a way to force the save and review the files later!

[Michael Bulgrien]

When in the IDE, you can open a 3-way merge with conflicts. You can close the merge without addressing the conflicts. BC3 asks if you want to save the merge results. You can specify yes or no. I am simply asking for the same functionality in a command line initiated merge. A parameter that allows me to save the merge output with conflicts. I thought /force would do that for me. In my opinion, that is what /force should do. Howerver, since it does not, I am proposing an additional parameter (/noconflictmarkers) that simply turns off the conflict markers. How difficult could that be to implement?

[Zoë]

I'm obviously missing something here. You're using "/automerge /reviewconflicts" aren't you? /reviewconflicts and /force are mutually exclusive; you can use one or the other. If you use /reviewconflicts it opens the interactive merge. Any conflicts are resolved by taking non-conflicting lines from their respective sides and I think the conflicting lines are taken from the center. If you save interactively it does not add conflict markers.

[Michael Bulgrien]

Yes, I am currently using /automerge /reviewconflicts.

The reason I am using /automerge /reviewconflicts is because I did not have an option to /force with /noconflictmarkers.

I agree that /force and /reviewconflicts are mutually exclusive. I was not suggesting otherwise. If I am not using /reviewconflicts, then I would like to use /force with /noconflictmarkers.

[Michael Bulgrien]

Any conflicts are resolved by taking non-conflicting lines from their respective sides and I think the conflicting lines are taken from the center.

I would think that /favorright and /favorleft should override taking the conflicting lines from the center.

If you save interactively it does not add conflict markers.

Exactly! ... and I would like the same functionality from the command line.

[Zoë]

Use /automerge /force, pass the "wait" flag to shell.run, and when the program returns use WSH's RegEx support to find the conflict markers and replace them with just the favored side. The conflict markers look like:

<<<<<<
lines from left side
======
lines from right side
>>>>>>

So it should be pretty easy to just pull out your favored side.

[Michael Bulgrien]

Like I said... how difficult could it be to simply not put them there?

You are asking the user to jump through hoops to edit something out when a simple runtime parameter could simply prevent the insertion in the first place.

[Michael Bulgrien]

Use /automerge /force, pass the "wait" flag to shell.run, and when the program returns use WSH's RegEx support to find the conflict markers and replace them with just the favored side. The conflict markers look like:

<<<<<<
lines from left side
======
lines from right side
>>>>>>

So it should be pretty easy to just pull out your favored side.

I should say that I do appreciate your suggestion. It is a viable work-around and I do plan to use it. I'll watch the return code and programatically edit the merge file and remove the conflict markers if a conflict occurs. However, I do hope for a parameter to prevent this need in the future. Thanks.

[Michael Bulgrien]

I've completed my first run using the "work-around" and have come to the conclusion that just suppressing the conflict markers and their contents won't work. I was wanting to have the same content in the merge file after a command line merge that exists after an interactive merge and save without conflict resolution.

If you open the merge interactively, one of the input panes is merged into the output pane. Wether it is the center pane or a favored side, I can't be 100% sure...but at least the resulting file contains valid code. If you use /automerge /force, only the left and right sides are displayed within the conflict markers...the center code is not shown at all. So if I remove the conflict markers and the enclosed content, the entire conflict section is missing and the resulting file is not even sytaxually valid.

I guess I'll drop this request for an enhancement and just use the /reviewconflicts parameter when that functionality is working again.

[Zoë]

I didn't say to supress the conflict marker's content. In between the conflict markers is the content from the left and right side. If you're "favoring" the right side, I'd recommend removing from ">>>>>>" to "======", which would also remove the left file's contents, along with the "<<<<<<" line. That leaves the content of the right file within the conflict section intact, which should at least compile.

That's not the same as the interactive merge though, since that does a line-by-line merge within the conflict section, but as near as I can tell it does match what you originally asked for.

[Zoë]

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.

I'm not sure what you're asking for is all that wise though. We can't make any guarantees about the quality of the merge if conflicts occur, so user-interaction should be required, either through the GUI or by introducing the conflict markers. We'll discuss it here though; maybe Tim and Erik feel differently.