[deleted]
The largest Git repo
71–80 of 416 posts
Re: The largest Git repo
#72Earlier quoted context omitted.
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.
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...
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.
Re: The largest Git repo
#73I am kinda surprised that Microsoft doesn't use tfs - after all, it's their own version control system. But then again, we use tfs at work and not a day goes by on which I do not long for git.
Here is my cynical view: From what I know they have a history of not using their own tools. They didn't use SourceSafe, but Perforce. Then they made an effort to switch to TFS, realized that it sucks and moved on to git.
You can see the same pattern in Windows desktop apps. They didn't use MFC for themselves, didn't use Winforms, used WPF only a little.
Re: The largest Git repo
#74A handful of us from the product team are around for a few hours to discuss if you're interested.
Does the virtualization work equally well for lots of history as it does for large working copies? I have a 100k commit svn repo I have been trying to migrate but the result is just too large. Partly this is due to tons of revisions of binary files that must be in the repo. Does the virtualization also help provide a shallow set of recent commits locally but keep all history at the server (which is hundreds of gigs t…
GVFS helps in both dimensions, working copy and lots of history. For the lots of history case, the win is simply not downloading all the old content.
A GVFS clone will contain all of the commits and all of the trees but none of the blobs. This lets you operate on history as normal, so long as you don't need the file content. As soon as you touch file content, GVFS will download those blobs on demand.
Re: The largest Git repo
#75is GVFS portable to other OSes?
Re: The largest Git repo
#76A handful of us from the product team are around for a few hours to discuss if you're interested.
This is amazing, congrats. I worked on Windows briefly in 2005 (the same year git was released!) and was surprised at how well Source Depot worked, especially given the sheer size of the codebase and the other SCM tools at the time. Is there anything people particularly miss about Source Depot? Something SD was good at, but git is not?
Another interesting complaint is one that we hear from a lot of people who move from CVCS to DVCS: there are too many steps to perform each action. For example, "why do I have to do so many steps to update my topic branch". While we find that people get better with these things over time, I do think it would be interesting to build a suite of wrapper commands that roll a bunch of these actions up.
Re: The largest Git repo
#77What was performance like for the Source Depot system? It would be interesting to note the comparison between the old SDX system and GVFS.
Re: The largest Git repo
#78300GB of code WOW! Just for comparison the entire English Wikipedia dump including all media is about 50-60GB. What are you guys doing there and how large do you see this growing?
Most of that 300GB isn't text. There are test assets, images, videos, built binaries, vhd's, etc. Also, I should be clear that that 300GB is just at tip (no history). We can debate about whether or not those things should be checked into the repo but they are there now.
Whoa. 300GB with a shallow clone?! What size does the whole repo use on the server side?
Re: The largest Git repo
#79Linus must be very proud - his favourite software Windows - now depends on GIT.
I hope this largest repository has enough space for Clippy as Linus loves it.
Re: The largest Git repo
#80A handful of us from the product team are around for a few hours to discuss if you're interested.
How do you prevent data exfiltration? I mean, in theory you could restrict the visibility of repos to the user based on team membership/roles and so prevent a single person from unauditably exfiltrating the whole Windows source code tree. In contrast with a monorepo there likely won't be any alerts triggered if someone does do a full git clone, except for someone saturating his switch port...
What would someone do with the source code for Windows? No one in open source would want to touch it. No large company would want to touch it. Grey/black hats are probably happier with their decompilers. Surely it would be easier to pirate than build (assuming their build system scales with most build systems I've observed in the wild). No small company would want to touch it.
Anyway MS share source with various third parties (governments at least and I believe large customs in general) so any of these are a potential leak source.