9 ms·

I wonder why Windows is a single repository - Why not split it in separate modules? I can imagine tools like Explorer, Internet Explorer/Edge, Notepad, Wordpad,

I wonder why Windows is a single repository - Why not split it in separate modules? I can imagine tools like Explorer, Internet Explorer/Edge, Notepad, Wordpad, Paint, etc. all can stay in its own repository. I can imagine you can even further split things up, like a kernel, a group of standard drivers, etc. If that is not already the case (separate repos, that is), are the plans to separate it in the future?

howinator 9y ago
So, this is actually pretty common. I know that both Google and Facebook use a huge mono-repo for literally everything (except I think Facebook split out their Android code into a separate repo?). So, all of Facebook's and Google's code for front-end, back-end, tools, infrastructure, literally everything, lives in one repo. It's news to me that Windows decided to go that route too. Personally, I think submodules and git sub-trees suck, so I'm all for putting things in a monorepo.
- Jyaif 9y ago
  pros to big repo: -dont have to spend time to think about defining interfaces cons: -history is full of crap you dont care about -tests take forever to run -tooling breaks down completely, though thanks to MS the limit was increased seriously
  - bpicolo 9y ago
    Are the big monorepo companies actually waiting for global test suite completion for every change? I'd doubt that, I'm sure they're using intelligent tools to figure out what tests to actually run. Compute for testing is massively expensive at that scale so it's an obvious place to optimize
    - puzzle 9y ago
      Google's build and testing system is smart in which tests to run, as you suspect, but it still has a very, very large footprint.
      - bpicolo 9y ago
        Right. My point is that the monorepo almost certainly isn't a problem in this regard.
  - eyq1 9y ago
    I have always wondered how they deal with acquisitions and sales. I guess a single system makes sense there too.
  - pvg 9y ago
    -dont have to spend time to think about defining interfaces That seems like a design and policy choice, orthogonal to repos.
    - dullgiulio 9y ago
      Not really. It's easier to make a single atomic breaking change to how different components talk to each other if they are in the same repository. If they are in different repos, the change is not atomic and you need to version interfaces or keep backwards compatibility in some other way.
      - pvg 9y ago
        It's very much really. The fact that it's easier doesn't really matter - a repo is about access to the source code and its history with some degree of convenience. The process and policy of how you control actual change is quite orthogonal. You can have a single repo and enforce inter-module interfaces very strongly. You can have 20 repos and not enforce them at all. Same goes for builds, tests, history, etc. The underlying technology can influence the process but it doesn't make it.
  - cryptonector 9y ago
    You still have to do something about internal interfaces. The problem is that the moment you want to make a backwards-incompatible change to an internal interface now you have to go find users of it, and there go the benefits of GVFS... Or you can let the build and test system tell you what breaks (take a long coffee break, repeat as many times as it takes; could be many times). Or use something like OpenGrok to find all those uses in last night's index of the source. Defining what portions of the OS you'll have to look in for such changes helps a great deal. As to building and testing... the system has to get much better about detecting which tests will need to be re-run for any particular change. That's difficult, but you can get 95% of the way there easily enough.
- jonathanpoulter 9y ago
  How does a mono-repo company manage open sourcing a single part of their infrastructure if things are in one large repo? For example, if everything lived in one repo, how does Facebook manage open sourcing React? Or if I personally wanted to switch to one private mono-repo, how would I share individual projects easily?
  - Blackthorn 9y ago
    With difficulty. No, seriously, that's the answer.
  - asp2insp 9y ago
    We have an internal tool that allows us to mirror subdirectories of our monorepo into individual github repositories, and another tool that helps us sync our internal source code review tool with PRs etc.
    - jonathanpoulter 9y ago
      An internal tool which manages commits, between individual repos etc. does it not seem that this is a logical extension to git itself? A little like submodules, but being able to publish only parts of the sourcetree. Maybe it would be impossible to keep any consistency and leaking information from the rest of the tree.
  - euyyn 9y ago
    So open sourcing can mean three different things: The bad one is just dumping snapshots of the code into a public repo every so often. You need to make sure your dependencies are open source, have tools that rewrite your code and build files accordingly, and put them in a staging directory for publishing. The good one is developing that part publicly, and importing it periodically into your internal monorepo with the same (or similar) process to the one you use for importing any other third-party library. There's also a hybrid approach which is to try and let internal developers use the internal tooling against the internal version of the code, and also external developers, with external tooling, against the public version. That one's harder, and you need a tool that does bidirectional syncing of change requests, commits, and issues.
detaro 9y ago
their earlier blogpost goes into it a bit https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... : The first big debate was – how many repos do you have – one for the whole company at one extreme or one for each small component? A big spectrum. Git is proven to work extremely well for a very large number of modest repos so we spent a bunch of time exploring what it would take to factor our large codebases into lots of tenable repos. Hmm. Ever worked in a huge code base for 20 years? Ever tried to go back afterwards and decompose it into small repos? You can guess what we discovered. The code is very hard to decompose. The cost would be very high. The risk from that level of churn would be enormous. And, we really do have scenarios where a single engineer needs to make sweeping changes across a very large swath of code. Trying to coordinate that across hundreds of repos would be very problematic. After much hand wringing we decided our strategy needed to be “the right number of repos based on the character of the code”. Some code is separable (like microservices) and is ideal for isolated repos. Some code is not (like Windows core) and needs to be treated like a single repo.
rubyn00bie 9y ago
It'd probably be hell on earth for the developers/engineers if it was more than one repo. I'm sure the build process is non-trivial and with 4,000 people working on it, the amount of updates it gets daily is probably insane. Any one person across teams trying to keep this all straight would surely fail. Having done a lot of small git repos, I'm a big fan of one huge repo. It makes life easier for everyone, especially your QA team as it's less for them to worry about. In the future, anywhere I'm the technical lead I'm gonna push for one big repo. No submodules either. They're a big pain in the ass too.
- monksy 9y ago
  Most of the work that is the issue would be solved by meta repos and tools to keep components up to date and integrated upward.
hyperrail 9y ago
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.
vtbassmatt 9y ago
Really good question. Actually, splitting Windows up was the first approach we investigated. Full details here: https://www.visualstudio.com/learn/gvfs-design-history/ https://www.visualstudio.com/learn/gvfs-design-history/ Summary: - Complicates daily life for every engineer - Becomes hard to make cross-cutting changes - Complicates releasing the product - There's a still a core of "stuff" that's not easy to tease apart, so at least one of the smaller Windows repos would still have been a similar order of magnitude in most dimensions
- rbanffy 9y ago
  I remember that, in the 90's, you'd often get new UI elements in Office releases that then would eventually move into Windows. There was a technical reason - the cross-cutting - but there also seemed to be a marketing reason - the moment those UI elements became part of core Windows, all developers (yours truly included) would be able to use those elements, effectively negating Office the fresh look before the competition.
- cosinetau 9y ago
  This was a very interesting point. It sounds like there are some serious architectural limitations on Windows, and this makes me believe the same might be true for the NT kernel, and that MS might not be interested in doing heavy refactoring of it. I'm not a frequent Windows user, or a Windows dev at all. Does anyone know of any consequences that MS's decision might mean, if this hypothesis is true?
  - planteen 9y ago
    Google also uses a single giant repo...
    - cwyers 9y ago
      And Facebook.
    - monksy 9y ago
      Why is that a "good reason" to do it?
arjie 9y ago
Why split it into separate modules? Seeing that big companies are very successful with monorepos (Google, Facebook, Microsoft), has made me reconsider if repository modularization is actually worth it. There are a host of advantages to not modularizing repos, and I'm beginning to believe they outweigh those of modular repos.
- komali2 9y ago
  Wait so like, at google, Inbox and Android are in the same repo as ChromeOS and oh I dunno, Google Search? That doesn't make any sense at all...
  - andreasklinger 9y ago
    Unsure if all their clients are in the same repo as well but even if… Why doesn't this make sense. I personally think of a repo as of an index not a filesystem. You checkout what you need but there is one global constant state - which can eg be used for continuous integration tests
  - TylerE 9y ago
    It makes total sense when the expectation is that any engineer in the company can build any part of the stack at any time with a minimum of drama.
    - bitJericho 9y ago
      This just blew my mind. I'm gonna go home and see about combining all my projects. That seems very useful!
      - bronson 9y ago
        You don't have the same requirements as Google.
        bitJericho 9y ago
smilekzs 9y ago
> Before the move to Git, in Source Depot, it was spread across 40+ depots and we had a tool to manage operations that spanned them.
petters 9y ago
I have worked at a company using one repo per team and at Google which uses a big monorepo. I much prefer the latter. As long as you have the infrastructure to support it, I see no other downsides (obviously, Google does not use git).

howinator 9y ago

So, this is actually pretty common. I know that both Google and Facebook use a huge mono-repo for literally everything (except I think Facebook split out their Android code into a separate repo?). So, all of Facebook's and Google's code for front-end, back-end, tools, infrastructure, literally everything, lives in one repo. It's news to me that Windows decided to go that route too. Personally, I think submodules and git sub-trees suck, so I'm all for putting things in a monorepo.

Jyaif 9y ago
pros to big repo: -dont have to spend time to think about defining interfaces cons: -history is full of crap you dont care about -tests take forever to run -tooling breaks down completely, though thanks to MS the limit was increased seriously
- bpicolo 9y ago
  Are the big monorepo companies actually waiting for global test suite completion for every change? I'd doubt that, I'm sure they're using intelligent tools to figure out what tests to actually run. Compute for testing is massively expensive at that scale so it's an obvious place to optimize
  - puzzle 9y ago
    Google's build and testing system is smart in which tests to run, as you suspect, but it still has a very, very large footprint.
    - bpicolo 9y ago
      Right. My point is that the monorepo almost certainly isn't a problem in this regard.
- eyq1 9y ago
  I have always wondered how they deal with acquisitions and sales. I guess a single system makes sense there too.
- pvg 9y ago
  -dont have to spend time to think about defining interfaces That seems like a design and policy choice, orthogonal to repos.
  - dullgiulio 9y ago
    Not really. It's easier to make a single atomic breaking change to how different components talk to each other if they are in the same repository. If they are in different repos, the change is not atomic and you need to version interfaces or keep backwards compatibility in some other way.
    - pvg 9y ago
      It's very much really. The fact that it's easier doesn't really matter - a repo is about access to the source code and its history with some degree of convenience. The process and policy of how you control actual change is quite orthogonal. You can have a single repo and enforce inter-module interfaces very strongly. You can have 20 repos and not enforce them at all. Same goes for builds, tests, history, etc. The underlying technology can influence the process but it doesn't make it.
- cryptonector 9y ago
  You still have to do something about internal interfaces. The problem is that the moment you want to make a backwards-incompatible change to an internal interface now you have to go find users of it, and there go the benefits of GVFS... Or you can let the build and test system tell you what breaks (take a long coffee break, repeat as many times as it takes; could be many times). Or use something like OpenGrok to find all those uses in last night's index of the source. Defining what portions of the OS you'll have to look in for such changes helps a great deal. As to building and testing... the system has to get much better about detecting which tests will need to be re-run for any particular change. That's difficult, but you can get 95% of the way there easily enough.
jonathanpoulter 9y ago
How does a mono-repo company manage open sourcing a single part of their infrastructure if things are in one large repo? For example, if everything lived in one repo, how does Facebook manage open sourcing React? Or if I personally wanted to switch to one private mono-repo, how would I share individual projects easily?
- Blackthorn 9y ago
  With difficulty. No, seriously, that's the answer.
- asp2insp 9y ago
  We have an internal tool that allows us to mirror subdirectories of our monorepo into individual github repositories, and another tool that helps us sync our internal source code review tool with PRs etc.
  - jonathanpoulter 9y ago
    An internal tool which manages commits, between individual repos etc. does it not seem that this is a logical extension to git itself? A little like submodules, but being able to publish only parts of the sourcetree. Maybe it would be impossible to keep any consistency and leaking information from the rest of the tree.
- euyyn 9y ago
  So open sourcing can mean three different things: The bad one is just dumping snapshots of the code into a public repo every so often. You need to make sure your dependencies are open source, have tools that rewrite your code and build files accordingly, and put them in a staging directory for publishing. The good one is developing that part publicly, and importing it periodically into your internal monorepo with the same (or similar) process to the one you use for importing any other third-party library. There's also a hybrid approach which is to try and let internal developers use the internal tooling against the internal version of the code, and also external developers, with external tooling, against the public version. That one's harder, and you need a tool that does bidirectional syncing of change requests, commits, and issues.

detaro 9y ago

their earlier blogpost goes into it a bit https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... : The first big debate was – how many repos do you have – one for the whole company at one extreme or one for each small component? A big spectrum. Git is proven to work extremely well for a very large number of modest repos so we spent a bunch of time exploring what it would take to factor our large codebases into lots of tenable repos. Hmm. Ever worked in a huge code base for 20 years? Ever tried to go back afterwards and decompose it into small repos? You can guess what we discovered. The code is very hard to decompose. The cost would be very high. The risk from that level of churn would be enormous. And, we really do have scenarios where a single engineer needs to make sweeping changes across a very large swath of code. Trying to coordinate that across hundreds of repos would be very problematic. After much hand wringing we decided our strategy needed to be “the right number of repos based on the character of the code”. Some code is separable (like microservices) and is ideal for isolated repos. Some code is not (like Windows core) and needs to be treated like a single repo.

rubyn00bie 9y ago

It'd probably be hell on earth for the developers/engineers if it was more than one repo. I'm sure the build process is non-trivial and with 4,000 people working on it, the amount of updates it gets daily is probably insane. Any one person across teams trying to keep this all straight would surely fail. Having done a lot of small git repos, I'm a big fan of one huge repo. It makes life easier for everyone, especially your QA team as it's less for them to worry about. In the future, anywhere I'm the technical lead I'm gonna push for one big repo. No submodules either. They're a big pain in the ass too.

monksy 9y ago
Most of the work that is the issue would be solved by meta repos and tools to keep components up to date and integrated upward.

hyperrail 9y ago

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.

vtbassmatt 9y ago

Really good question. Actually, splitting Windows up was the first approach we investigated. Full details here: https://www.visualstudio.com/learn/gvfs-design-history/ https://www.visualstudio.com/learn/gvfs-design-history/ Summary: - Complicates daily life for every engineer - Becomes hard to make cross-cutting changes - Complicates releasing the product - There's a still a core of "stuff" that's not easy to tease apart, so at least one of the smaller Windows repos would still have been a similar order of magnitude in most dimensions

rbanffy 9y ago
I remember that, in the 90's, you'd often get new UI elements in Office releases that then would eventually move into Windows. There was a technical reason - the cross-cutting - but there also seemed to be a marketing reason - the moment those UI elements became part of core Windows, all developers (yours truly included) would be able to use those elements, effectively negating Office the fresh look before the competition.
cosinetau 9y ago
This was a very interesting point. It sounds like there are some serious architectural limitations on Windows, and this makes me believe the same might be true for the NT kernel, and that MS might not be interested in doing heavy refactoring of it. I'm not a frequent Windows user, or a Windows dev at all. Does anyone know of any consequences that MS's decision might mean, if this hypothesis is true?
- planteen 9y ago
  Google also uses a single giant repo...
  - cwyers 9y ago
    And Facebook.
  - monksy 9y ago
    Why is that a "good reason" to do it?

arjie 9y ago

Why split it into separate modules? Seeing that big companies are very successful with monorepos (Google, Facebook, Microsoft), has made me reconsider if repository modularization is actually worth it. There are a host of advantages to not modularizing repos, and I'm beginning to believe they outweigh those of modular repos.

komali2 9y ago
Wait so like, at google, Inbox and Android are in the same repo as ChromeOS and oh I dunno, Google Search? That doesn't make any sense at all...
- andreasklinger 9y ago
  Unsure if all their clients are in the same repo as well but even if… Why doesn't this make sense. I personally think of a repo as of an index not a filesystem. You checkout what you need but there is one global constant state - which can eg be used for continuous integration tests
- TylerE 9y ago
  It makes total sense when the expectation is that any engineer in the company can build any part of the stack at any time with a minimum of drama.
  - bitJericho 9y ago
    This just blew my mind. I'm gonna go home and see about combining all my projects. That seems very useful!
    - bronson 9y ago
      You don't have the same requirements as Google.
      - bitJericho 9y ago

smilekzs 9y ago

> Before the move to Git, in Source Depot, it was spread across 40+ depots and we had a tool to manage operations that spanned them.

petters 9y ago

I have worked at a company using one repo per team and at Google which uses a big monorepo. I much prefer the latter. As long as you have the infrastructure to support it, I see no other downsides (obviously, Google does not use git).