At Microsoft, there's a movement to get onto Git from our ancient proprietary centralized version control system, and my impression is we're slowly but surely getting there. Open Source projects are hosted on Github, and proprietary projects are hosted in Git repos in Visual Studio Team Services.
Part of the reason that the migration is taking a while is that some code bases are way too big for Git to handle without slowing to a crawl. To deal with that, the VSTS team made the Git Virtual File System. Awesomely, they made it open source!
(note: I do work for Microsoft but not for the VSTS team; I'm also not trying to speak for the whole company in any official way :) )
I am a passionate programmer who would love to work with great like-minded people. I came to dev.to because of the outstanding content it has, and I'm hoping I will contribute to this awesomeness!
Location
Arbutus, MD
Education
Graduate Student, University Of Maryland Baltimore County
At Google we have out own version control (git but not github). When I was at Yahoo we used Enterprise Github (in addition to Yahoo's own SVN). Our Open Source stuff is on github, of course.
Google doesn't use GitHub, or Git. Instead they have their own, pretty insane system called Piper. There is only one Piper repository. Different projects are different subdirectories within the same massive repository.
As a result, there's no way to clone the entire repository to your computer. The standard way to handle this is something called Clients in the Cloud, or CitC. Basically the entire repository is mounted as a virtual filesystem, and you can do whatever you want with it.
It's not sane to try to fix merge conflicts in such a big repo. That problem is solved by (almost) eliminating branching or merging. Piper's branching support is very limited, and the only time it's used is for releases. Generally, there's only one branch.
There's also only one version of everything: the latest version. There's no old versions kept around for things that haven't updated to the new versions. If you make a backwards incompatible change to an API, you have to then go and update everything that uses your API. Which you can do, since everything's in the same repository. There are even automated tools you can use for this.
Hmm. Interesting stuff about Piper indeed :)
Though, I saw some Google projects being mirrored to GitHub. Also, fuchsia.googlesource.com/ shows they keep some projects on their own "Google Git" kind of thing.
Maybe that's only true for their open source projects and the internals are kept in Piper as you mentioned
The Chromium and Android people do use Git, but only because their projects are open source and nobody outside Google can use Piper. They do a lot of things with it that are inspired by Piper though, such as copying all their dependencies into the repository in a directory called third_party.
I've read about Facebook's use of Mercurial, so as of the last I've read they don't even use git. But I'd guess all of these companies use GitHub on some level. FB, for example does all of that open source stuff with GitHub, so I'd be curious about where they draw lines and choose where to do what.
Amazon as an organization is pretty modular - they have teams working on lots of different projects and technologies. While I would expect the CodeCommit team to be using CodeCommit, it wouldn't surprise me if other teams used other CVS systems. You can further splice that by teams on projects under AWS, teams that work on devices, teams that work on their shopping, teams that work on physical distribution, etc.
Sounds awful. I'm a victim of their business modularity, as I need to get structured metadata into their various national systems, and their vendor-facing systems, support, and documentation are a shambles.
At Bloomberg we use Enterprise GitHub to foster internal collaboration and transparency. All but the most sensitive repositories are (internally) public so anyone can send a Pull Request for fixes and enhancements.
Most major code management services offer a "behind the firewall" solution, typically branded Enterprise, that allow companies to host their content (and security, auditing, etc.) entirely themselves. Contributions to OSS are entirely separate affairs and have a process. You rarely see a project incubated as OSS, instead internal projects are converted at some point for any number of reasons.
It also mentions that Google has some internal use for Git too, and faced/fixed similar scaling problems, and both (Google and MS) are considering proposing their stuff to upstream Git too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
At Microsoft, there's a movement to get onto Git from our ancient proprietary centralized version control system, and my impression is we're slowly but surely getting there. Open Source projects are hosted on Github, and proprietary projects are hosted in Git repos in Visual Studio Team Services.
Part of the reason that the migration is taking a while is that some code bases are way too big for Git to handle without slowing to a crawl. To deal with that, the VSTS team made the Git Virtual File System. Awesomely, they made it open source!
(note: I do work for Microsoft but not for the VSTS team; I'm also not trying to speak for the whole company in any official way :) )
According to this article, at Google, they store all of their code in a single repository!
thats pretty nuts
Got any insight on this @ginader ?!
At Google we have out own version control (git but not github). When I was at Yahoo we used Enterprise Github (in addition to Yahoo's own SVN). Our Open Source stuff is on github, of course.
Thank you for the insight. Very interesting stuff
Google doesn't use GitHub, or Git. Instead they have their own, pretty insane system called Piper. There is only one Piper repository. Different projects are different subdirectories within the same massive repository.
As a result, there's no way to clone the entire repository to your computer. The standard way to handle this is something called Clients in the Cloud, or CitC. Basically the entire repository is mounted as a virtual filesystem, and you can do whatever you want with it.
It's not sane to try to fix merge conflicts in such a big repo. That problem is solved by (almost) eliminating branching or merging. Piper's branching support is very limited, and the only time it's used is for releases. Generally, there's only one branch.
There's also only one version of everything: the latest version. There's no old versions kept around for things that haven't updated to the new versions. If you make a backwards incompatible change to an API, you have to then go and update everything that uses your API. Which you can do, since everything's in the same repository. There are even automated tools you can use for this.
You can read more about it here: cacm.acm.org/magazines/2016/7/2040...
There simply has to be some tool called "pied" at google which interfaces with this piper repository using some fancy compression algorithm.
Hmm. Interesting stuff about Piper indeed :)
Though, I saw some Google projects being mirrored to GitHub. Also, fuchsia.googlesource.com/ shows they keep some projects on their own "Google Git" kind of thing.
Maybe that's only true for their open source projects and the internals are kept in Piper as you mentioned
The Chromium and Android people do use Git, but only because their projects are open source and nobody outside Google can use Piper. They do a lot of things with it that are inspired by Piper though, such as copying all their dependencies into the repository in a directory called
third_party.I've read about Facebook's use of Mercurial, so as of the last I've read they don't even use git. But I'd guess all of these companies use GitHub on some level. FB, for example does all of that open source stuff with GitHub, so I'd be curious about where they draw lines and choose where to do what.
Thanks so much for the Facebook intel. Interesting read for sure.
Didn't Facebook write the phabricator platform? It'd make sense for them to be using that.
At Amazon, most teams use git, but not GitHub.
I'd be amazed if they're not eating their own CodeCommit dogfood.
aws.amazon.com/codecommit/
Amazon as an organization is pretty modular - they have teams working on lots of different projects and technologies. While I would expect the CodeCommit team to be using CodeCommit, it wouldn't surprise me if other teams used other CVS systems. You can further splice that by teams on projects under AWS, teams that work on devices, teams that work on their shopping, teams that work on physical distribution, etc.
Sounds awful. I'm a victim of their business modularity, as I need to get structured metadata into their various national systems, and their vendor-facing systems, support, and documentation are a shambles.
At Bloomberg we use Enterprise GitHub to foster internal collaboration and transparency. All but the most sensitive repositories are (internally) public so anyone can send a Pull Request for fixes and enhancements.
Did you mean git?
I actually meant GitHub specifically but thats another good question
Don't confuse the terminology then
Git - version control system
Github - web hosting for git
Most major code management services offer a "behind the firewall" solution, typically branded Enterprise, that allow companies to host their content (and security, auditing, etc.) entirely themselves. Contributions to OSS are entirely separate affairs and have a process. You rarely see a project incubated as OSS, instead internal projects are converted at some point for any number of reasons.
Here's an article about how MS is migrating to Git and what've they had to change in it to work for their use case (scaling issues mostly)
arstechnica.com/information-techno...
It also mentions that Google has some internal use for Git too, and faced/fixed similar scaling problems, and both (Google and MS) are considering proposing their stuff to upstream Git too.