4 ms·

Wrong. Google has the exact same problem, only they chose to rewrite Perforce. The scale of these codebases is way outside what most people have experienced an

Wrong. Google has the exact same problem, only they chose to rewrite Perforce. The scale of these codebases is way outside what most people have experienced and it might behoove people to realize that a lot of conventional wisdom might not apply. E.g. last time I checked, Google's codebase was >2Billion lines of code. Google has 30,000 engineers working on a "monolithic" codebase and remain relatively productive despite (or perhaps because of it). There are whole sets of different problems at this scale.

emu 10y ago
See https://www.youtube.com/watch?v=W71BTkUbdqE https://www.youtube.com/watch?v=W71BTkUbdqE for a lot more details on what Google does.
- kyrra 10y ago
  And Google has been contributing to Mercurial. Like subtree: https://bitbucket.org/Google/narrowhg https://bitbucket.org/Google/narrowhg
pvelagal 10y ago
2 billion lines of code @ 80 characters per line (with 2 bytes per character) = 320 GB of code, fits on my mac SSD. Wonder if 30,0000 engineers , sending 30,000 requests per second to server(s) with 320GB of code (can be put in memory) is a huge problem (edit) in terms of scale, especially when these same engineers build systems for handling billions of requests ?
- steffan 10y ago
  You're not considering that it's not just the current 2 billion lines of code - it's the history of the repo, branches, forks, possibly binaries thrown in.
  - pvelagal 10y ago
    I never built any source code system, so not an expert, but isnt branching snapshotting the current version of file(s) (strings), and newer versions are about calculating deltas. Arent, most of the Operations in a source code mgmt system, are diffs and merges of strings. Basically, my point is, scale problems associated with these systems are not at the same level as other scalability problems handled by google's core competency areas such as search which deal with billions of requests or peta bytes of data. Not that they are easy, but that orders of magnitude smaller.
amaks 10y ago
It's also very beneficial to the code health as it allows to make global refactoring, e.g. adopting new language features, improving shared libraries, etc.

emu 10y ago

See https://www.youtube.com/watch?v=W71BTkUbdqE https://www.youtube.com/watch?v=W71BTkUbdqE for a lot more details on what Google does.

kyrra 10y ago
And Google has been contributing to Mercurial. Like subtree: https://bitbucket.org/Google/narrowhg https://bitbucket.org/Google/narrowhg

pvelagal 10y ago

2 billion lines of code @ 80 characters per line (with 2 bytes per character) = 320 GB of code, fits on my mac SSD. Wonder if 30,0000 engineers , sending 30,000 requests per second to server(s) with 320GB of code (can be put in memory) is a huge problem (edit) in terms of scale, especially when these same engineers build systems for handling billions of requests ?

steffan 10y ago
You're not considering that it's not just the current 2 billion lines of code - it's the history of the repo, branches, forks, possibly binaries thrown in.
- pvelagal 10y ago
  I never built any source code system, so not an expert, but isnt branching snapshotting the current version of file(s) (strings), and newer versions are about calculating deltas. Arent, most of the Operations in a source code mgmt system, are diffs and merges of strings. Basically, my point is, scale problems associated with these systems are not at the same level as other scalability problems handled by google's core competency areas such as search which deal with billions of requests or peta bytes of data. Not that they are easy, but that orders of magnitude smaller.

amaks 10y ago

It's also very beneficial to the code health as it allows to make global refactoring, e.g. adopting new language features, improving shared libraries, etc.