cannot modify stream while there are incoming changes
With parallel development there are times when I need to promote changes from a stream with a subset of components into a stream that has a superset. I understand that when there are merge conflicts it is necessary to do the merge in a workspace. But when there are no conflicts, I still get the message "cannot modify stream while there are incoming changes" and RTC suggests that I accept the "missing" components before trying to deliver. I get the same message whether I try to deliver from A --> B or accept B --> A (in Eclipse).
Accepted answer
I predict that someone set the "Require Workspaces to Be Caught Up Before Delivery" Deliver(server) precondition.
Assuming you are getting this message from the Team Advisor view, you would see as the Reason: "Only allow delivery from workspaces that are caught up with the stream they are delivering to".
That precondition considers that if a component in the stream does not exist in the workspace, then that workspace is not caught up to the stream.
When you say that you get the message from "accept B --> A", is A the workspace and B the stream, and does "accept B -> A" mean you are "accepting changes from workspace A into stream B"? If so, that is equivalent to delivering from workspace A into stream B, and will activate the deliver precondition.
As a side note, I noticed that turning on this precondition effectively disallows direct stream-to-stream delivery if there are outgoing changes in both directions between the two streams (because trying to send the changes in either direction violates the precondition of one of the two streams).
Assuming you are getting this message from the Team Advisor view, you would see as the Reason: "Only allow delivery from workspaces that are caught up with the stream they are delivering to".
That precondition considers that if a component in the stream does not exist in the workspace, then that workspace is not caught up to the stream.
When you say that you get the message from "accept B --> A", is A the workspace and B the stream, and does "accept B -> A" mean you are "accepting changes from workspace A into stream B"? If so, that is equivalent to delivering from workspace A into stream B, and will activate the deliver precondition.
As a side note, I noticed that turning on this precondition effectively disallows direct stream-to-stream delivery if there are outgoing changes in both directions between the two streams (because trying to send the changes in either direction violates the precondition of one of the two streams).
Comments
Thank you Geoffrey. Yes, I probably should have written accept B <-- A to indicate my attempt to accept into the stream from a workspace (hoping to dodge the precondition).
I had to wade my way through to the parent scope which is linked in the Overview to see where the Preconditions are set for all of our projects.