As Brian Harry alluded to, this is in fact very close to the previous system. As I recall it from my time at Microsoft: The Windows source control system used

As Brian Harry alluded to, this is in fact very close to the previous system. As I recall it from my time at Microsoft: The Windows source control system used to be organized as a large number (about 20 for product code alone, plus twice that number for test code and large test data files) of independent master source repositories. The source checkouts from these repos would be arranged in a hierarchy on disk. For example, if root\ were the root of your working copy, files directly under root\ would come from the root repo, files under root\base\ from the base repo, root\testsrc\basetest from basetest, and so on. To do cross repo operations you used a tool called "qx" (where "q" was the name of the basic source control client). Qx was a bunch of Perl scripts, some of which wrapped q functions and others that implemented higher-level functions such as merging branches. However, qx did not try to atomically do operations across all affected repos. (The closest analog to this in git land would be submodules.) While source control was organized this way, build and test ran on all of Windows as a single unit. There was investigation into trying to more thoroughly modularize Windows in the past, but I think the cost was always judged too great. Mark Lucovsky did a talk several years ago on this source control system, among other aspects of Windows development: https://www.usenix.org/legacy/events/usenix-win2000/tech.html https://www.usenix.org/legacy/events/usenix-win2000/tech.htm... I believe it is still valid for folks not using GVFS to access Windows sources.