6 ms·

IMHO it is a major failure that git doesn’t scale for org-wide mono repos. Software development process should not be dictated by limitations in the VCS. It sur

IMHO it is a major failure that git doesn’t scale for org-wide mono repos. Software development process should not be dictated by limitations in the VCS. It surprises me that others are so willing to settle.

_s 9y ago
Would you be willing to elaborate on the pros/cons of mono repos vs what git encourages? It seems to just be the wrong fit for a given use case, but works very well others.
- ed_blackburn 9y ago
  That's a good and valid point, which deserves a conversation undoubtedly - however, there are a lot of businesses out there who have a large monolith, legacy application gigabytes in size where the cost of slicing and dicing into smaller repositories has to be driven by requirements and not technology. My current client has a 17-year-old multi Gb TFS monolith. New components go into git and as features evolve it's common for the respective team to hive them off into they're own git repos as stand-alone components. Nevertheless TFS is painful and if I could have an effective git repo with the monolith too, then life would be far easier.
  - ryanisnan 9y ago
    Is there a way to split a TFS repository, surely you no longer need the past 10 years of commit history on a daily basis - archive it or something? Also how feasible is migrating from TFS to Git?
    - Merad 9y ago
      Very, thanks to git-tfs [1]. My company is in the midst of a move from on premise TFS/TFVC to cloud based VSTS/git. We've run into some projects that managed to somehow mangle their branch history so to the point that we gave up and only migrated the current checkin to git, but most projects pull out the full history and all branches with no trouble. The only real complaint I have is speed. Dunno if it's our TFS server or the nature of TFS, but every checkin pulled into git takes anywhere from 5-30 seconds. In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. [1]: https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs
      - josteink 9y ago
        > In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. If it makes you feel any better I had to spend two continuous weeks exporting our huge TFS monolith before I managed to have a working git copy. But yeah, Git-TFS is a godsend.
jonhohle 9y ago
Is there a VCS that does? When I was at Amazon, Perforce couldn't scale (it had already been partitioned into a few depots, but those had reached their reasonable capacity). Amazon moved to a per "module" git-repo system. It was convenient to push across multiple repos simultaneously, but it wasn't a deal breaker when we lost it (I never heard of any workflows being completely unworkable following the transition).
- oconnor663 9y ago
  Google has one internally, and Facebook has done a ton of work on Mercurial to build something similar, doing things like replacing files on disk with memcache servers running close to the dev machines. But I don't think there's anything that works "out of the box" at that scale.
  - QuercusMax 9y ago
    For quite a while at Google there have been git extensions/tools for working with Piper. They're pretty widely used, but haven't been "officially" supported. There's a new project that allows you to use hg with Piper/CitC; I've been using it for about a month and it's been working really well. No clue how it works, though.
- jsolson 9y ago
  Piper: https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... Unfortunately, it's not available externally. Even working at Google, my jaw still dropped at this: Google's codebase is shared by more than 25,000 Google software developers from dozens of offices in countries around the world. On a typical workday, they commit 16,000 changes to the codebase, and another 24,000 changes are committed by automated systems. Each day the repository serves billions of file read requests, with approximately 800,000 queries per second during peak traffic and an average of approximately 500,000 queries per second each workday. Most of this traffic originates from Google's distributed build-and-test systems. Mostly I felt terribly unproductive — my changelist generation rate is way below average.
jlgaddis 9y ago
> IMHO it is a major failure that git doesn’t scale for org-wide mono repos. git was (initially) written by Torvalds to serve his own purpose -- he needed a new VCS for Linux. Let's say that it "doesn't scale for org-wide mono repos". Unless that was a design goal (and I'm pretty sure it wasn't), how is that a "failure"? It apparently works just fine for the kernel developers. Yet because it didn't work well for Microsoft's 300 GB worth of tens millions of lines of code it is somehow a "failure"? Apparently Microsoft's own TFS is a failure too, then, because it seems that it wasn't up to the task either.
- ryanisnan 9y ago
  There's also the popularity factor... not many care(d) about TFS. I would refrain from calling most pieces of technology a "failure", git especially. When your screwdriver does a bad job at pounding nails, you're doing it wrong.
- ethomson 9y ago
  PM at Microsoft here. TFVC is completely different, though. (To quickly clarify nomenclature: TFVC is "Team Foundation Version Control", the name of the centralized version control system in TFS and VSTS, which are our on-premises and cloud hosted development platforms, respectively. They both support both TFVC and Git - Git with GVFS, and they do more than just version control, hence the naming clarification. Apologies for all the three letter acronyms.) Anyway, TFVC is totally different and a centralized version control system with all the workflows that go along with it like expensive branching. The desire to move to Git opens up all the awesome workflows that Git offers. The impetus here was to standardize the entire company on a modern set of development tools - one engineering system across the company - hosted in Visual Studio Team Services. We could have moved them to TFVC, it's remarkably similar to its predecessor, "Source Depot" which is a Microsoft internal tool that the Windows team was using. But that's a lateral move. There aren't really any benefits to TFVC over Source Depot except that we sell and support one to end users and don't with the other. So that has some nice organizational benefits but not enough to warrant moving everybody and the build/release farms over. But moving to Git unlocks all sorts of new workflows - lightweight branching, pull requests, all that good stuff that everybody who uses Git is totally used to. Anyway, that's the background on Git vs TFVC. And, no, I totally agree that Git not supporting giant monorepos is not a failing, per se. But it is a limitation, and thankfully one that we're working to help overcome.
hasenj 9y ago
What I find more surprising is the length they went through to make git work for them. It would probably have been better if they had assigned a team of highly skilled engineers to design a distributed source control from scratch specifically to solve the problems faced by the windows team. After all, `git` itself was developed for Linux because Linus was not satisfied with any of the existing solutions.
- sverhagen 9y ago
  Why would that have been better? (Why in the world would that have been better?)
  - hasenj 9y ago
    For the same reason that git turned out better than svn for a lot of use cases. It seems like Windows is not really one of these use cases.

_s 9y ago

Would you be willing to elaborate on the pros/cons of mono repos vs what git encourages? It seems to just be the wrong fit for a given use case, but works very well others.

ed_blackburn 9y ago
That's a good and valid point, which deserves a conversation undoubtedly - however, there are a lot of businesses out there who have a large monolith, legacy application gigabytes in size where the cost of slicing and dicing into smaller repositories has to be driven by requirements and not technology. My current client has a 17-year-old multi Gb TFS monolith. New components go into git and as features evolve it's common for the respective team to hive them off into they're own git repos as stand-alone components. Nevertheless TFS is painful and if I could have an effective git repo with the monolith too, then life would be far easier.
- ryanisnan 9y ago
  Is there a way to split a TFS repository, surely you no longer need the past 10 years of commit history on a daily basis - archive it or something? Also how feasible is migrating from TFS to Git?
  - Merad 9y ago
    Very, thanks to git-tfs [1]. My company is in the midst of a move from on premise TFS/TFVC to cloud based VSTS/git. We've run into some projects that managed to somehow mangle their branch history so to the point that we gave up and only migrated the current checkin to git, but most projects pull out the full history and all branches with no trouble. The only real complaint I have is speed. Dunno if it's our TFS server or the nature of TFS, but every checkin pulled into git takes anywhere from 5-30 seconds. In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. [1]: https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs
    - josteink 9y ago
      > In large projects with long histories you can easily spend 30+ minutes exporting history before running into a problem that prevents the export from completing. If it makes you feel any better I had to spend two continuous weeks exporting our huge TFS monolith before I managed to have a working git copy. But yeah, Git-TFS is a godsend.

jonhohle 9y ago

Is there a VCS that does? When I was at Amazon, Perforce couldn't scale (it had already been partitioned into a few depots, but those had reached their reasonable capacity). Amazon moved to a per "module" git-repo system. It was convenient to push across multiple repos simultaneously, but it wasn't a deal breaker when we lost it (I never heard of any workflows being completely unworkable following the transition).

oconnor663 9y ago
Google has one internally, and Facebook has done a ton of work on Mercurial to build something similar, doing things like replacing files on disk with memcache servers running close to the dev machines. But I don't think there's anything that works "out of the box" at that scale.
- QuercusMax 9y ago
  For quite a while at Google there have been git extensions/tools for working with Piper. They're pretty widely used, but haven't been "officially" supported. There's a new project that allows you to use hg with Piper/CitC; I've been using it for about a month and it's been working really well. No clue how it works, though.
jsolson 9y ago
Piper: https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... Unfortunately, it's not available externally. Even working at Google, my jaw still dropped at this: Google's codebase is shared by more than 25,000 Google software developers from dozens of offices in countries around the world. On a typical workday, they commit 16,000 changes to the codebase, and another 24,000 changes are committed by automated systems. Each day the repository serves billions of file read requests, with approximately 800,000 queries per second during peak traffic and an average of approximately 500,000 queries per second each workday. Most of this traffic originates from Google's distributed build-and-test systems. Mostly I felt terribly unproductive — my changelist generation rate is way below average.

jlgaddis 9y ago

> IMHO it is a major failure that git doesn’t scale for org-wide mono repos. git was (initially) written by Torvalds to serve his own purpose -- he needed a new VCS for Linux. Let's say that it "doesn't scale for org-wide mono repos". Unless that was a design goal (and I'm pretty sure it wasn't), how is that a "failure"? It apparently works just fine for the kernel developers. Yet because it didn't work well for Microsoft's 300 GB worth of tens millions of lines of code it is somehow a "failure"? Apparently Microsoft's own TFS is a failure too, then, because it seems that it wasn't up to the task either.

ryanisnan 9y ago
There's also the popularity factor... not many care(d) about TFS. I would refrain from calling most pieces of technology a "failure", git especially. When your screwdriver does a bad job at pounding nails, you're doing it wrong.
ethomson 9y ago
PM at Microsoft here. TFVC is completely different, though. (To quickly clarify nomenclature: TFVC is "Team Foundation Version Control", the name of the centralized version control system in TFS and VSTS, which are our on-premises and cloud hosted development platforms, respectively. They both support both TFVC and Git - Git with GVFS, and they do more than just version control, hence the naming clarification. Apologies for all the three letter acronyms.) Anyway, TFVC is totally different and a centralized version control system with all the workflows that go along with it like expensive branching. The desire to move to Git opens up all the awesome workflows that Git offers. The impetus here was to standardize the entire company on a modern set of development tools - one engineering system across the company - hosted in Visual Studio Team Services. We could have moved them to TFVC, it's remarkably similar to its predecessor, "Source Depot" which is a Microsoft internal tool that the Windows team was using. But that's a lateral move. There aren't really any benefits to TFVC over Source Depot except that we sell and support one to end users and don't with the other. So that has some nice organizational benefits but not enough to warrant moving everybody and the build/release farms over. But moving to Git unlocks all sorts of new workflows - lightweight branching, pull requests, all that good stuff that everybody who uses Git is totally used to. Anyway, that's the background on Git vs TFVC. And, no, I totally agree that Git not supporting giant monorepos is not a failing, per se. But it is a limitation, and thankfully one that we're working to help overcome.

hasenj 9y ago

What I find more surprising is the length they went through to make git work for them. It would probably have been better if they had assigned a team of highly skilled engineers to design a distributed source control from scratch specifically to solve the problems faced by the windows team. After all, `git` itself was developed for Linux because Linus was not satisfied with any of the existing solutions.

sverhagen 9y ago
Why would that have been better? (Why in the world would that have been better?)
- hasenj 9y ago
  For the same reason that git turned out better than svn for a lot of use cases. It seems like Windows is not really one of these use cases.