Hey there Zach,
So I have followed up internally, and this is very much something we are theoretically exposed to, but due to our rate of churn in main-line this is not something we practically encounter (we generate PCB builds quite frequently, almost at a rate of every 5 or so minutes).
Some higher level feedback from the SME in this space:
- CL based engine versioning doesn’t accomplish it’s intended goals in a RoboMerge environment, as CL verification is really only valid in a single stream
- We are forcing the CL# in to every manually built version of the editor via UGS instead of having version 0 for the built engine, this means that there isn’t even the guarantee within a single stream that the user running an editor with cl# after the asset # can load it because the engine could have had local incompatible issues, and submitted the asset without submitting the changes that created them
Fundamentally speaking, the CL based versioning has it’s challenges in a Robomerge environment, but at the moment we tend to work around/with those challenges. I hope this provides some clarity on the limitations of Robomerge in this scenario, and that you indeed aren’t experiencing a unique edge case to your setup. I don’t see any efforts internally to address this at the moment due to the low incidence we encounter.
Kind regards,
Julian