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 *A*lice from accounting wanting to take a piece of code that *B*ob 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?