30 ms·

It's kind of interesting that nowadays people assume that version control system == git. For a huge, non-open codebase there are some pretty large downsides to

It's kind of interesting that nowadays people assume that version control system == git. For a huge, non-open codebase there are some pretty large downsides to a fully distributed VCS in exchange for relatively few benefits.

hossbeast 9y ago
Such as? Then why has everyone switched to git? (Hint, because it is fundamentally built on more powerful ideas than what came before it)
- emodendroket 9y ago
  Well clearly not "everyone" has since we're apparently talking about a company that hasn't.
- joshuamorton 9y ago
  Open source has moved to git, mostly because being standardized on one vcs made it easier for people to contribute. A lot of companies don't use git.
  - davidgay 9y ago
    No, before git the standard was svn, and before that, cvs. The switches happened even though there was an existing standard.
    - progre 9y ago
      Having worked with all three, nothing but Stockholm syndrome would keep anyone to switch from cvs. Likevise the switch to git for open source happend (In my opinion) in large part because Github offers a far better experience than SourceForge witch was dominant at the time.
      - boulos 9y ago
        There was actually a brief period where Google Code was ascendant, but then GitHub was demonstrably investing more in collaboration. I think one aspect of Git that is really important is forking, and having your own local commits. Merging commits and patches in svn were awful. You wouldn't ever allow someone random to join your svn repo, but if they can reasonably provide a patch, you could take it. Git makes that massively easier.
        TheArcane 9y ago
        >There was actually a brief period where Google Code was ascendant, brrrr
        alphaalpha101 9y ago
        >I think one aspect of Git that is really important is forking, and having your own local commits. Do you mean branching? Git doesn't have any concept of forking. What GitHub calls 'forking' isn't forking at all.
- kevin_thibedeau 9y ago
  People switched to Git because Svn merging continues to suck and branching and tagging are implemented in the most inane way possible.
  - Const-me 9y ago
    I didn't care about merging and tagging. For me the main feature was distributed nature. SVN is OK on a gigabit corporate LAN with dedicated people to manage & maintain the servers + network. Anything less than that, and it becomes slow and unreliable.
malux85 9y ago
Could you please elaborate? I've only used svn and git, and the largest codebases I've worked on have only been about 150k lines of code. What are the other ones and the main differences, really curious
- dfox 9y ago
  For example in svn checking out only some subdirectory instead of entire repo is pretty much the default way how you should use it.
- deleted 9y ago
  [deleted]
- vvanders 9y ago
  Perforce is really common in a few domains because it handles 1TB+ repo sizes cleanly, has simple replication, locking of binary files and a good UI client for non-programmers. Was pretty much used exclusively back when I was in gamedev, not sure if that's still the case.
- nerfhammer 9y ago
  git is designed from the ground up to be 100% distributed. This is useful for small and/or open source projects. It's 100% portable. You can fork and merge between different repos maintained by complete strangers. Now, imagine you're a huge corporation. Your code consists of millions of files that have been edited millions of times. It's never going to be released to the public. It's never going to be forked, much less by a stranger. You're going to have only one main branch and main build ever, except for maintenance branches. The complete history of everything that has ever happened on that repo is would take up many gigabytes, and developers are probably only ever going to need to look at and/or build locally 0.01% of that code themselves. If you were going to design a version control system from scratch for the latter scenario and you had never heard of git or any other existing VCS, how would you design it? Would you come up with something like git? Probably not. People would just have local copies of the minimum of what they needed to get their work done, anything else would call some server on the VPN they were always on. And you would probably come up with some whole specialized server architecture with databases and such that wasn't that similar to a corresponding client architecture that it would also need.
hota_mazi 9y ago
Good point. It's important to stress that Google uses Perforce and not git (at least for that monorepo, they use git/gerrit for Android). A monorepo this size would simply not scale on git, at least not without huge amounts of hacks (and to be fair, Google built an entire infrastructure on top of Perforce to make their monorepo work).
- joshuamorton 9y ago
  Google no longer uses perforce either. I believe it also stopped scaling. They now use Piper, which has a perforce like interface, but is not the same thing. And there are other non perforce like Piper interfaces.
- dmoy 9y ago
  Google doesn't use perforce anymore. It's been replaced with Piper, you can read about it in articles from about 2015 or so. Perforce didn't scale enough. I guess it's not clear to what extent Piper is a layer of infrastructure on top of perforce or actually a complete rewrite? I was never super sure. The articles appear to imply way more than a layer on top... You are exactly right that git doesn't scale though, go see the posts on git that Facebook's engineers made while trying, only to be met with replies to the extent of "you're holding it wrong, go away, no massive monorepo here", at which point they made it work with mercurial instead. Good read though, lot of good technical details. Can't find the link at the moment though :(, but it was from somewhere around 2012-13 ish. Edit: here, looks like the original thread is deleted but here's the hn pointer: https://news.ycombinator.com/item?id=3548824 https://news.ycombinator.com/item?id=3548824
  - justinjlynn 9y ago
    There's nothing wrong with saying "you're holding it wrong" if they're holding it in a way clearly contrary to the solution design. I don't fit in a toddler's car seat and if I tried, it's clearly my fault and not the seat engineer's. I doubt they'd want to accept my changes that would make it work worse for toddlers either.
    - 9y ago

hossbeast 9y ago

Such as? Then why has everyone switched to git? (Hint, because it is fundamentally built on more powerful ideas than what came before it)

emodendroket 9y ago
Well clearly not "everyone" has since we're apparently talking about a company that hasn't.
joshuamorton 9y ago
Open source has moved to git, mostly because being standardized on one vcs made it easier for people to contribute. A lot of companies don't use git.
- davidgay 9y ago
  No, before git the standard was svn, and before that, cvs. The switches happened even though there was an existing standard.
  - progre 9y ago
    Having worked with all three, nothing but Stockholm syndrome would keep anyone to switch from cvs. Likevise the switch to git for open source happend (In my opinion) in large part because Github offers a far better experience than SourceForge witch was dominant at the time.
    - boulos 9y ago
      There was actually a brief period where Google Code was ascendant, but then GitHub was demonstrably investing more in collaboration. I think one aspect of Git that is really important is forking, and having your own local commits. Merging commits and patches in svn were awful. You wouldn't ever allow someone random to join your svn repo, but if they can reasonably provide a patch, you could take it. Git makes that massively easier.
      - TheArcane 9y ago
        >There was actually a brief period where Google Code was ascendant, brrrr
      - alphaalpha101 9y ago
        >I think one aspect of Git that is really important is forking, and having your own local commits. Do you mean branching? Git doesn't have any concept of forking. What GitHub calls 'forking' isn't forking at all.
kevin_thibedeau 9y ago
People switched to Git because Svn merging continues to suck and branching and tagging are implemented in the most inane way possible.
- Const-me 9y ago
  I didn't care about merging and tagging. For me the main feature was distributed nature. SVN is OK on a gigabit corporate LAN with dedicated people to manage & maintain the servers + network. Anything less than that, and it becomes slow and unreliable.

malux85 9y ago

Could you please elaborate? I've only used svn and git, and the largest codebases I've worked on have only been about 150k lines of code. What are the other ones and the main differences, really curious

dfox 9y ago
For example in svn checking out only some subdirectory instead of entire repo is pretty much the default way how you should use it.
deleted 9y ago
[deleted]
vvanders 9y ago
Perforce is really common in a few domains because it handles 1TB+ repo sizes cleanly, has simple replication, locking of binary files and a good UI client for non-programmers. Was pretty much used exclusively back when I was in gamedev, not sure if that's still the case.
nerfhammer 9y ago
git is designed from the ground up to be 100% distributed. This is useful for small and/or open source projects. It's 100% portable. You can fork and merge between different repos maintained by complete strangers. Now, imagine you're a huge corporation. Your code consists of millions of files that have been edited millions of times. It's never going to be released to the public. It's never going to be forked, much less by a stranger. You're going to have only one main branch and main build ever, except for maintenance branches. The complete history of everything that has ever happened on that repo is would take up many gigabytes, and developers are probably only ever going to need to look at and/or build locally 0.01% of that code themselves. If you were going to design a version control system from scratch for the latter scenario and you had never heard of git or any other existing VCS, how would you design it? Would you come up with something like git? Probably not. People would just have local copies of the minimum of what they needed to get their work done, anything else would call some server on the VPN they were always on. And you would probably come up with some whole specialized server architecture with databases and such that wasn't that similar to a corresponding client architecture that it would also need.

hota_mazi 9y ago

Good point. It's important to stress that Google uses Perforce and not git (at least for that monorepo, they use git/gerrit for Android). A monorepo this size would simply not scale on git, at least not without huge amounts of hacks (and to be fair, Google built an entire infrastructure on top of Perforce to make their monorepo work).

joshuamorton 9y ago
Google no longer uses perforce either. I believe it also stopped scaling. They now use Piper, which has a perforce like interface, but is not the same thing. And there are other non perforce like Piper interfaces.
dmoy 9y ago
Google doesn't use perforce anymore. It's been replaced with Piper, you can read about it in articles from about 2015 or so. Perforce didn't scale enough. I guess it's not clear to what extent Piper is a layer of infrastructure on top of perforce or actually a complete rewrite? I was never super sure. The articles appear to imply way more than a layer on top... You are exactly right that git doesn't scale though, go see the posts on git that Facebook's engineers made while trying, only to be met with replies to the extent of "you're holding it wrong, go away, no massive monorepo here", at which point they made it work with mercurial instead. Good read though, lot of good technical details. Can't find the link at the moment though :(, but it was from somewhere around 2012-13 ish. Edit: here, looks like the original thread is deleted but here's the hn pointer: https://news.ycombinator.com/item?id=3548824 https://news.ycombinator.com/item?id=3548824
- justinjlynn 9y ago
  There's nothing wrong with saying "you're holding it wrong" if they're holding it in a way clearly contrary to the solution design. I don't fit in a toddler's car seat and if I tried, it's clearly my fault and not the seat engineer's. I doubt they'd want to accept my changes that would make it work worse for toddlers either.
  - 9y ago