Jump to content


Jozy Zim

Member Since 16 Jul 2019
Offline Last Active Mar 23 2020 10:51 PM
-----

Posts I've Made

In Topic: Merge reporting nearly identical files as a single massive conflict, refuses...

23 March 2020 - 10:52 PM

View PostSambwise, on 13 February 2020 - 05:44 AM, said:

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.

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!

In Topic: Merge reporting nearly identical files as a single massive conflict, refuses...

13 February 2020 - 12:19 AM

Thanks, Sambwise! Your tips got the problem solved, but if anyone is interested, some more detail.

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!