Slashdot Mirror
Windows Switch To Git Almost Complete: 8,500 Commits and 1,760 Builds Each Day (arstechnica.com)
An anonymous reader quotes a report from Ars Technica: Back in February, Microsoft made the surprising announcement that the Windows development team was going to move to using the open source Git version control system for Windows development. A little over three months after that first revelation, and about 90 percent of the Windows engineering team has made the switch. The Windows repository now has about 4,400 active branches, with 8,500 code pushes made per day and 6,600 code reviews each day. An astonishing 1,760 different Windows builds are made every single day -- more than even the most excitable Windows Insider can handle.
Say what you will about Mr. Torvalds, but that magnificent bastard has smacked down many a foe over the years. This is really sweet. If the only thing Linus ever did was to invent git, then that would have been enough. But no, he had to write an operating system besides. When history is written, Linus's inspiration will shine forth from the Pantheon of greats.
How come they didn't go with Mercurial?
Some obvious reasons off the top of my head:
You can also make the argument that Git was designed from the beginning to be suitable for developing an operating system. Or, put more bluntly, it was designed to be used by programmers who are smart enough to work on an operating system, Yes, the Mercurial CLI is generally easier to come to grips with, but that isn't a compelling enough reason on its own.
Keep in mind also that the overall direction of Mercurial is increasingly being driven by the needs of Facebook's dev teams. Which is great to see, in the sense that they're returning their enhancements to the community..... but by and large they're building web properties, not operating systems, so the priorities may be different.
When did they stop using Visual Source Safe ?
Microsoft Visual SourceSafe was first released in 1994, so by my estimate they stopped using it in 1994.
Anons need not reply. Questions end with a question mark.
I ran a git pull origin master, which seemed to work fine, but now I have a bunch of code that's copyright 1993 Digital Equipment Corporation?
The work they've done to make Git scale to fit their needs sounds great, and I see they've open-sourced the key components. That's awesome. At the moment it looks like GVFS is Windows-only (not a big surprise -- and not a complaint; they built what they needed). I'd like to see someone port it to Linux and make this infrastructure more broadly available. It sounds like it would be much nicer to work on than the "repo" tool that Android layers on top of Git to enable managing a whole bunch of smaller repositories.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
The article summary also leaves out the minor point that MS had to write an entire abstraction layer underneath Git because it's so incapable of handling a large repository.
Not completely true. They call it GVFS, but all it really does is prevent the entire repository from being downloaded when you clone it. Instead it downloads "only what you need". And there are a couple of patches to make git aware that this is happening, so that it stats only what is local and not the whole repository. One might argue that since the developer teams are not working on the entire codebase at once but rather on, let's call them "modules", within the larger repository, then the repository itself should be made more modular that match this development pattern. That would be more inline with the way Git was designed in the first place, and these extensions would not be as necessary. Still, to have the capability is nice.
Just because your favorite version control system can't do something doesn't mean it's a bad idea.
No, but pick the right tool for the job. If you are not developing modular, self-contained code in a decentralized fashion, don't use a source control system designed with those explicit goals in mind.
Notice how LibreOffice splits up their fairly large codebase into several smaller repositories,
https://github.com/LibreOffice
Seems to work pretty well for them.
You obviously didn't RTFA. They had to create this GVFS thing because their code base is huge and they don't want to sync hundreds of gigs between remote locations. Also they were not using VSS before switching to Git, they were using Perforce.
It's not a WTF. It's a great achievement and will probably become a standard component of large-scale git repos. If you ever had to deal with huge repos that are used by teams in many timezones you'd understand that.
For reference, the Linux kernel git repo is about 6GB all in. The Windows git repo is 300GB. We can all guess that in that 300GB there's a fair amount of dead wood but still, in an era where storage is dirt cheap, one shouldn't have to trim down a code source repo because the vcs can't keep up.
lucm, indeed.