Why should one avoid cross-team (circular) merges in multiple-team version control?

Question

Please excuse the artwork, I know it looks like an elongated imperial shuttle, but it's the way I visualise a multiple team (or multiple stream) version control strategy. The central core, is the trunk (or master) repository. If there were lots more streams you can imagine more planes projecting out from the trunk, in which various branching and merging is taking place within those streams (the thinner lines).

The red line shows Alice from accounting wanting to take a piece of code that Bob from the backups team has only just forged (she needs it urgently for some reason that I can't think of). Actually, it's not like a one line change that she can just do herself. Instead you can consider that accounting are heavily blocked and need a large change set from Backups to continue.

Now as I understand it, this is against best-practice, and the changes required should go through the trunk, and Alice should pick them up that way, rather than take the short cut illustrated (a version control wormhole). However, although I have seen this stated in various places, I have never seen some deep, lengthy and well-justified reasons why a cross-stream (or circular?) merge is something not to allow. The only thing I can think of is that I guess it can lead to greater manual conflict resolution.

So questions are:

• Why is allowing a cross-stream merge bad? (I need some well-defined reasons to convince my various-minded colleagues why it shouldn't be done)
• Are there any justifiable reasons to go against best-practice?
• What if Alice's team is reaching a release deadline, can there be an exception?

Answer 1

After reading through the TFS branching and merging documentation I couldn't come up with a sensible answer for your questions. According to the doc's it's perfectly okay to have different streams of development on one product in their own branches. I guess the best arguments against this scenario are:

• greater complexity in merging and conflict resolution over multiple streams to the root
• possibility of overlapping work (multiple teams might resolve same issue differently)
• splitting up development efforts over various teams and coordinating that effort requires good communication and change management between the teams

So when you look at it, its not a technology issue that "blocks" this scenario.

Answer 2

Now as I understand it, this is against best-practice, and the changes required should go through the trunk, and Alice should pick them up that way, rather than take the short cut illustrated

Why so??? Final task is (after all) getting product, not blindly follow policy. Cross-team communication is nice, if it serves final task - "getting thing done"