Jump to content

Daniel B

Member Since 05 Feb 2019
Offline Last Active Feb 20 2019 08:58 AM

Posts I've Made

In Topic: Differentiating between unresolved vs "resolve -ay" integrations

06 February 2019 - 02:30 AM

Aha, that doesn't quite help in my situation, but pointed me in the right direction!

In practice, many of the files we're seeing this issue on are binaries (image files) and the people doing conflict resolution are inspecting each file and using P4V to select which one to keep - so unfortunately can't rely on them running a specific undocumented resolve option on the CLI :)

I'm also understandably wary of messing with server-wide configs that could affect other projects, regardless of how much I still think dm.integ.tweaks=2 should be true for most cases.

But both of these led me to what looks like the silver bullet I was hoping for: the integration script pushing from Authority to Outsource simply has to use the undoc "integrate -Znnn" option:
p4 integ -S //stream/Child -r -Z2
p4 resolve -as
and truly unresolved conflicts are still flagged, while anything resolved in favour of either parent is synchronised without issue.

Thanks for your help!

In Topic: Differentiating between unresolved vs "resolve -ay" integrations

06 February 2019 - 12:29 AM

View PostSambwise, on 05 February 2019 - 03:19 PM, said:

I think the crux of what you're hitting is that "resolve -ay" creates divergence between streams, and (more importantly) the default behavior of a subsequent "p4 merge" is to preserve that divergence in both directions.

In other words, in the first image, the merge into Outsource is attempting to propagate changes 77 and 78 into Outsource while also preserving change 75 (which exists in Outsource but not Authority).

Yes, that's exactly it - if this is working as intended, it's bonkers! There's a world of difference between "This is the correct change to be implemented in this file" and "That change should be isolated to that stream/branch".
For starters, wanting to create a divergence like that is far more likely if there were no corresponding change in Authority - in which case one would have to manually force a resolve despite the lack of conflict, then do a "resolve -ay" to ignore the change from Outsource.

Secondly, in this example I actually never explicitly performed a "resolve -ay" - all conflicts were resolved through the p4merge GUI.
This was the merge back to Authority that led to change 80 in file1 (which fails to propagate back to Outsource):
Attached File  resolve3merge.jpg   92.63K   34 downloads
Whereas this is the same merge for file3 (which propagates as expected):
Attached File  resolve3merge-both.jpg   91.8K   33 downloads

The fact that 2 such logically similar operations create such a difference behind the scenes by default is concerning, especially when the difference could be as little as one character of whitespace left in or out.

View PostSambwise, on 05 February 2019 - 03:19 PM, said:

If you want *all* of your "resolve -ay" records to be treated like the second image, there's actually a configurable on the server to do exactly that:

dm.integ.tweaks 0 Modify integrate behavior (engine=3 only):
1: Treat all 'copy' records as 'merge'
2: Treat all 'ignore' records as 'edit'

See the "esoteric configurables" section of the "Base Picking" white paper: https://swarm.worksh...ase Picking.pdf

Thanks, I'll look into that. I can imagine there is definitely a use for marking a given change as something to be preserved but isolated to a given branch, but in the middle of conflict resolution is absolutely not it. Surely there should be a separate command to mark a change as such!