Merge reporting nearly identical files as a single massive conflict, refuses to break differences down more discretelyp4v merge conflict
Posted 12 February 2020 - 10:57 PM
The first 11 lines are identical.
The source file has two lines changed (one commented out, one added) next to each other at 12/13.
The target file has one additional line ~30 lines later. The intervening 36 lines are almost identical. 12 of them have whitespace differences only that P4V is not able to recognize as such.
The remaining 35 lines are identical, not even white space differences.
P4Merge would see the first two lines as a possible conflict and ask for help. It would see the intervening space of dozens of lines as identical and not part of some massive connected block. If strict white space is being asked for, each individual line would be treated on its own terms at worst, or grouped together between any lines that have no differences. The single line in the target would be seen as a separate and isolated difference, even if its a conflict.
P4V has decided to gather from these files is that after the first 11 lines, the subsequent 71/72 lines are in complete and irreconcilable conflict with each other.
Also baffling, is the Resolve tool reports 5 conflicts.
But opening the merge tool, only 1 conflict is reported/found.
The 5 conflicts sounds really promising! How could I access that breakdown?
I've tried picking one of the sides of the conflict, and then editing the file to correct the missing data from the other side, but P4V refuses to complete the merge, locking all files that are part of the merge for having been modified outside of the process, and forcing a complete revert of the entire merge attempt (despite only one file violating this hidden rule).
I've tried all the Ignore line spacing/white space options to try and get a better diff report (because of the inconsequential white space differences), but nothing changes the merge analysis.
By comparison, when I use the built-in diff tool (Mac OSX bash, GNU 2.8.1) it gives me a sensible breakdown of differences that, if P4V had broken it up as finely, I could work with. (Which, perhaps not coincidentally, reports 5 chunks of differences if I don't ignore white space, and only two differences - what I actually care about - if white space is ignored).
Is there a way I can get P4V to more aggressively break up the massive conflict block into something useful and actionable?
I'm using the latest MAC Client:
Posted 12 February 2020 - 11:24 PM
1. Is there a version discrepancy between the server (P4D), the client (P4V), and the merge tool (P4Merge)? Each of these has the merge logic compiled into it, and if they're of wildly different vintages, you might get different behavior from them. I believe the "merge preview" you get from the resolve dialog is calculated inside the client library (i.e. inside P4V) using flags and file data sent by the server, but I'm not positive about that...
2. Are the merge tool and the "p4 resolve" command using the same whitespace settings? (e.g. if you see "p4 resolve -dw" in P4V's log pane that would correspond with "ignore whitespace differences" in P4Merge)
It sounds like whatever merge calculation "p4 resolve" is doing is the one you want, so it's just a matter of figuring out how to bring P4Merge into alignment with "p4 resolve".
Alternatively, you could drop out to the command line and run "p4 resolve" there; one of the options it'll give you is to do a merge in your text editor.
Posted 13 February 2020 - 12:19 AM
1. Aside from Mac vs Linux, the server and client looked pretty similar (both marked as 2018.1) but I'm not sure how to verify that they are the same (the last two images are the client and server). I wouldn't be surprised if there was a big difference. Whereas P4Merge was something like 2019.2. It sounded more recent. Anyway, I downloaded the latest (2020 Jan 9) P4Merge and got the same results (I didn't update the P4V client at first, but have done so since resolving the issue).
As I poked around, my theory is that p4 resolve was directly comparing the files, while P4Merge was creating a "difference map" using assumptions based on Perforce file history (and the bad conflicting result could make sense, given the unusual paths these files have taken). I was able to get the Resolve window, from additional actions, to give me a diff that looked like a '5 Conflict' solution. But I wasn't able to translate that into any kind of resolution via the GUI. It seemed informational only.
2. The white space settings were the same as far as it looked from the GUI. If I set them to ignore all, the Resolve went from 5 conflicts to 2, what I would expect (matching GNU diff). Conversely, once inside the P4Merge, it stayed at the massive '1 Conflict' regardless of white space settings. Whatever I had set Resolve to, Merge opened with those settings (it just didn't matter). Before going down this rabbit hole of looking up command logs and such, however, I decided to try 'p4 resolve' on the command line and that solved the problem.
Using 'p4 resolve' gave me what looked like the '5 conflict' version, similar to what I was seeing with the diff GNU tool. Using the command line, I could make the edits and was able to successfully merge as I had originally expected this process to go. Phew!
Posted 13 February 2020 - 05:44 AM
FWIW, this should not be true. Each resolve is a simple three-way merge; all P4Merge should get as its inputs as far as the file contents go are those three inputs (the base and two legs). The base and the "theirs" leg are determined on the server at the time that the resolve is scheduled (e.g. during "p4 integrate" or "p4 sync"), and the "yours" leg is always the local workspace file. Regardless of whether you merge from the command line or from a GUI tool (and regardless of which GUI tool), those three input files should be the same because "p4 resolve" is driving the merge in all cases.
Based on your description it sounds like there's a decent chance that the latest version of P4Merge has some kind of bug pertaining to whitespace handling; that might be worth following up on with Perforce support...
Posted 23 March 2020 - 10:52 PM
I agree, although it seems p4 merge has always been a little screwy (for decades). During this process I upgraded p4 merge from whatever version I was using (early or mid 2019) to Jan 9 2020 (latest at the time of my previous post) and the behavior's been essentially the same.
Just last week I was doing another merge that was much like this set-up (one file is outside the workspace, being merged into the workspace), and p4 merge saw the files as completely different, despite the real difference being less than 4 lines. Luckily only one had changes I wanted, so I was able to ignore its mess and take from source.
Before seeing the difference in behavior between merge and resolve with this issue, I had written off Perforce as just having bad difference analysis for years. If it's a bug, it's one they've been sitting on for a very long time, doing nothing but giving the whole system a bad name. I'm now not clear why they don't scrap it and let resolve do all the work, since it actually works!
Posted 24 March 2020 - 03:46 PM
to be clear: are you talking about the whitespace settings in P4V or in P4Merge? Because IIRC P4Merge has its *own* unique whitespace settings that are completely independent of the flags that you pass to "p4 resolve". I think P4V is probably supposed to try to synchronize them but it would not surprise me at all if that doesn't always work -- however you should be able to just toggle the setting once you're inside P4Merge.
Also tagged with one or more of these keywords: p4v, merge, conflict
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users