P4V not prompting to take merge result when BC4 is used as merge tool

[IkerGimenez]

Hi!

Previously I had used BC4 as my merge and diff tool in Perforce with no issues. When I started using it again after changing jobs, Perforce suddenly seems to not take the merge result when using BC4 as a merge tool unless I make change like write a space, save, delete the space, and save again. Am I missing something from the setup so P4V correctly reads the merge result file when using BC4? Is this a P4V bug?

Thanks,
Iker

[Aaron]

Hello,

I've seen one other similar report. In that case, P4V was passing in 4 parameters to the mergetool. The three input parameter variables were expanded out into their values (%1 -> c:\temp\filepath\file.txt) but the output variable wasn't, and was passed in as a working directory and the literal text "%r" (%r -> c:\directory\%r) which fails.

Is that what is happening with you? Which version of P4V and OS are you running on, and are there any p4v updates you can apply? And if so, can you open a ticket with Perforce? Please feel free to include our support email from our contact information and we'd be glad to help with what is going wrong.
https://www.scootersoftware.com/index.php?zz=contact

[IkerGimenez]

Hi Aaron,

I'm not sure to be honest. The BC4 window does open, and everything works fine, except for when it has automatically done the merge with no conflicts to resolve. In those cases, I have to modify the [MERGE] file to get P4V to prompt me to save the merge result into VCS. In other words, if there are conflicts, once I resolve them, save the merge result, and close BC4, P4V prompts me to save the result of the merge operation. If there are no conflicts but it did perform a merge (the [MERGE] file contains changes from both sources), when I close BC4, P4V does not prompt me to save the result of the merge operation.

My setup uses C:/Program Files/Beyond Compare 4/BComp.exe as the target executable and passes %1 %2 %b %r so it might be similar to the case you've mentioned.

I'm running Windows 10 64 bit, latest verison of P4V (Rev. P4V/NTX64/2022.2/2336701).

If you don't think this is on BC4's side, I'll go ahead an open a bug ticket for P4V.

Cheers,
Iker

[Aaron]

Hello,

When no conflicts are detected, P4V still calls to and launches the BC4 graphical interface, correct? And there are four file paths: 3 on the top and one in the 'middle' (above the output pane). Do all the paths look correct and well formed? What is the text of the output file path? If it's the above issue it's fairly obvious in that it includes the literal "%r" as text in the path it passed in. Though from your description, it doesn't sound like that is the issue here.

We don't have a copy of Perforce here, but my guess is that the Output content is pre-generated by Perforce (since there are no conflicts). BC4 then opens the 4 file paths when it is called and generates the Output content itself. If the generated Output pane content already matches what is in the parameter file path, the save icon is disabled; if the output location is empty or otherwise does not match the generated Output pane content, then the save icon is live.

We haven't changed this behavior and it's been working for many years up to this point, so there may have been a change in Perforce's behavior. If it went from detecting when BComp.exe closed to looking for a modified timestamp update to the Output file (from when it generated it to making sure it was updated after detecting BComp.exe closed)?

This is in contrast with some other version control solutions that I've tested, where if there are no conflicts and the version control generates the output itself, then it never calls out to the external mergetool; it auto-merges those files itself.

If you can open that ticket (as a customer of theirs), I'd be grateful. I think this would be a bug, but it might be a new expectation and they could let us know what it is they think we should be doing instead.

[IkerGimenez]

Aaron,

I opened up a ticket with Helix. I'll let you know what they respond.

Cheers,
Iker

[IkerGimenez]

Hi Aaron,

Looks like it's a known P4V bug:

Hi Iker

Thank you for the detailed description. That helped me find the following bug report (I haven't copied all the bug description, rather I've extracted the most relevant parts):

job087769 : Problems with resolved files not getting picked up after a merge.

The issue seems to be in P4V as this is reproducable in both Araxis and Beyond Compare 4.

The issue is that after doing a merge and resolving conflicts in a file, we'll encounter a file where the resolution of the conflicts didn't seem to take correctly and we'll end up with the conflict markers and unresolved code in the final output, but P4V thinks the file was successfully merged and uses an unresolved version of the file.

It does seem to be timing related - whether it's the timing between saving and quitting the merge tool, to the dialog popping up the accept prompt, or something else, no one knows.


I think that describes what you are experiencing quite well and I have added this case to the job. If there's anything else you'd like to add please let me know.

I don't think there much more I can add from a support perspective.

Thank you for your time,
Iker

[Aaron]

Hello,

Very much appreciated. We don't have special access, so opening a ticket as a customer is a great way to get something started. If they have any questions, we're available to help.