Jump to content


Daniel B

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

Topics I've Started

Differentiating between unresolved vs "resolve -ay" integrations

05 February 2019 - 08:20 AM

I'm trying to manage automated upstream integrations between 2 streams, with occasional manual downstream pulls. There's context below on how and why our streams are set up to get to this state, but the core of the issue is:

If a branched file is modified in both //stream/Parent and //stream/Child (or just related branches, this isn't exclusive to streams), then those changes are merged and resolved downstream into //stream/Parent, it seems to be impossible to safely automate getting the merged result back to //stream/Child.

p4 integ -S //stream/Child -r
p4 resolve -at
// AKA
p4 copy -S //stream/Child -r -F
is unsafe - it will blindly overwrite conflicts that have not been resolved.

p4 integ -S //stream/Child -r
p4 resolve -as
will usually work - leaves unresolved conflicts unresolved (exactly what we want), doesn't checkout conflicts that have been "resolve -at" in //stream/Parent, and copies back up changes from either "resolve -am" or p4merge by a user in //stream/Parent.
Where it fails is anything that was resolved in //stream/Parent with "resolve -ay" or a p4merge that resulted in content identical to //stream/Parent/file.

This is the end result:
Attached File  resolveIssue.jpg   62.53K   37 downloads

This seems pretty bugged to me, is it intended? If so, how can we mark a revision as "this version is correct and should be propagated to related streams"?

Context on stream setup:
I know the default "merge down, copy up" paradigm wouldn't allow this to happen because ALL changes would be resolved into one stream before blindly copying into the other, but that is not quite a perfect fit for our needs, whether //stream/Child is treated as stable or unstable.
We have an "Authority" mainline with occasional well-tested commits, and an "Outsource" child which frequent, potentially unstable changes are submitted to.
All commits to Authority should be integrated ASAP to Outsource - this is the automated process I'm maintaining. Since there will be as-yet unapproved changes in Outsource, it cannot be a "Stable" stream unless I go "against the flow" when integrating across. This seems like the best option, but hits the issue described above.

However, since all integrations from Outsource to Authority are performed by taking one or more (but not all) changes, resolving any merge conflicts, then testing in the stable environment before committing that piece of work, we need to merge into Authority, so Outsource can't be a "Development" stream either (again, unless we go "against the flow" and integrate to Authority, setting us up for the same issue).