There was essentially instability and chaos in the big dev heavy divisions at MS when they all worked in one branch, but that led very rapidly to more sophisticated models with more points of validation between the average dev and the common code/builds that qa and everyone else shared and used.
The common pattern nowadays is to code review each commit, build each commit on Jenkins & pass tests, git bisect, etc...
What was the procedure back then ?
Do you mean before or after? Before, it was "do your best", which was never enough, not with everyone partying in the same branch. After, it was a matter of breaking things up into different feeder branches down to individual teams. Code that goes "up" into more mainline branches is required to have a higher QC bar in order to get in, such as a full clean build of the entire set of sources (which for something like windows, office, or visual studio / .net could take a very long time) and running the entire set of build verification tests with zero failures (also a long process). Code would go up during an integration window, there would inevitably be some instability that would need cleaned up (test failures, maybe code breaks sometimes) which would get stabilized, then code would flow back "down" to individual teams from those good builds. And code would flow up further into other branches that would be shared and used by more teams around the division/company.
Most dev groups these days use different systems because they tend not to have such monolithic projects, they can leverage automation better, and it's rare to have literally thousands of devs all working on the same software. When you can only get a few builds out per day, or maybe only one, then you have to become a lot more careful at keeping a separation between devs coding away at their desktops and the builds that everyone else depends on.
