Is this allowed in Global Configurations?
Hi,
Accepted answer
As Thomas mentions above, having two or more different configurations of the same component in a GC hierarchy is allowed, but it creates a condition called "component skew". Component skew affects which configuration is used to resolve an artifact version. The ambiguity of component skew is resolved using the order of the configurations in the hierarchy, with the first one (by a depth-first search traversal) being given precedence.
Comments
Ok, this makes sense and I have tried it in the test area. So basically, if a user was viewing the Motor component's RM artifacts in the context of the "Vessel 1" the local RM config would be selected based on skew resolution rules (because it can't show the artifact content for both Port side and Starboard side motors).
Glyn, I'm not sure where the motor component fits in as I don't see it represented in the original hierarchy you shared.
I agree with all of Tom's comments, except for the "skew is not necessarily wrong" comment. I believe that using a GC with skew will virtually always result in significant user confusion, and very likely significant errors (for the reason TomK identifies in his answer). I believe the only purpose of skew is to allow you to temporarily be in a skewed state as you transition to a new configuration, but that you should never leave a configuration in a skewed state. If you need to have two "variants" of a component in the same system, I recommend having a separate component for each variant.
One other answer
Comments
Is it still "Skew" if they were under their own global configuration in the GC hierarchy?
this does not make a difference.
It's still skew if you're using the same root GC, Vessel 1, because the two configurations of the same component have a common ancestor. But, if each of your skewed RM configurations had their own GC, and you set your RM context to one of those GCs, then there would be no skew at that level of the hierarchy. That is, if the you narrow the scope of your context, you may be able to eliminate skew in that context.
So, if you have skew at the top level of the hierarchy, but still want users to be able to work on a non-preferred local configuration in some (narrower) GC context, introducing an intermediate GC like "GC: Generator STBD" is a way to achieve this. That makes the most sense if you have other contributions in that same narrower context, such as a QM configuration with test cases for that RM configuration's requirements. As long as you use "GC: Generator STBD" as your GC context in RM, links between those RM and QM contributions will be resolved within that narrower context, which is what you want.
But, if you try to resolve such links in a broader context (say Vessel 1), then the skew resolution rules are going to use "RM: Generator Port" rather than "RM: Generator STBD".