New requirements don't appear in modules in open change sets - module binding issue (ERM DOORS Next)?
I'm looking for confirmation of what I think is going on in our ERM DOORS Next project area, and what the best approach is to fix it.
Scenario: ERM version 7.0.2 iFix035 with CM enabled. User has multiple change sets open for the same module, where each one is adding new requirements (plus some modifications). One of the change sets was delivered, new requirements were added to the module, everything looks okay in the stream.
Something seems to have gone wrong with sync'ing the open change sets with the stream. The new base artifacts are there, quick search will find both the base artifact and the artifact in the module, but those new requirements don't appear in the module itself. From what I've read this means the module binding failed (couldn't add those rows to the module)?
I think the issue is that they have too many open change sets that all affect the module structure. ERM can't resolve this properly. If I compare the change set to the stream it doesn't show this as an issue or conflict but I'm afraid that if I deliver any of the other change sets, I'll corrupt the stream as well.
Is this a known behaviour or maybe new defect (any I've found should be fixed in my version)? Are we doing things wrong by having too many overlapping change sets open at the same time? Is there an easy way to resolve this or should we discard them all and start over?
2 answers
It's not a defect - in the context of each changeset once the module structure has been changed there's a local version of the structure which doesn't know about structure changes being made in the stream or in other changesets. The new base artifacts will all be visible but none of the other structure changes will.
Deliver the changesets resolving conflicts as necessary and in the stream the combined results will be visible.
Certainly if you're making many parallel changes to the structure of the module you're likely to have to do a lot of conflict resolution - it's best to create the changeset and make these changes and deliver quickly so that the other users do the same - i.e. as few parallel changesets with module edits as possible.