4 ms·

That's a non-issue for scalable version control systems they use - perforce and now its in-house replacement (piper). Gamedev companies LOVE perforce because i

That's a non-issue for scalable version control systems they use - perforce and now its in-house replacement (piper). Gamedev companies LOVE perforce because it scales, they keep game assets in it and those can be huge.

CivBase 5y ago
By "scalable" I assume you mean "centralized". As in the repository is hosted on a single machine, so you only have to worry about one machine meeting the hardware requirements for storing all that data. That scales better with repo size, but it scales worse with the size of your development team. I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine.
- quantumofalpha 5y ago
  > By "scalable" I assume you mean "centralized". Yes, at scale it has to be. Google has hundreds of terabytes of data in their monorepo, you can't check out it all! Historically centralized used to be the norm - previous popular VCS generations (CVS, subversion) are all like that. DVCS (git & co) came into dominance only in the last decade or so. > That scales better with repo size, but it scales worse with the size of your development team. Google switched to piper around 2014 when they had ~50k employees. Perforce monorepo worked pretty well for them until then. It has certain costs to scale a monorepo that far - lots of investment into tooling to make it all work, needs dedicated teams. But it can be scaled. And it offers certain benefits that are very difficult to harness in multi-repo setups - ability to reason about and refactor code across entire repo is the biggest one. > I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine Linux kernel development is very different, decentralized across many different companies and ICs, hence the need for DVCS systems like git. In a corporate environment like google or gamedev, it is much easier to keep version control centralized and dedicate a team to maintaining it.
  - CivBase 5y ago
    Right. I just wanted to point out that centralized and distributed version control are both designed to scale, just in different ways.

CivBase 5y ago

By "scalable" I assume you mean "centralized". As in the repository is hosted on a single machine, so you only have to worry about one machine meeting the hardware requirements for storing all that data. That scales better with repo size, but it scales worse with the size of your development team. I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine.

quantumofalpha 5y ago
> By "scalable" I assume you mean "centralized". Yes, at scale it has to be. Google has hundreds of terabytes of data in their monorepo, you can't check out it all! Historically centralized used to be the norm - previous popular VCS generations (CVS, subversion) are all like that. DVCS (git & co) came into dominance only in the last decade or so. > That scales better with repo size, but it scales worse with the size of your development team. Google switched to piper around 2014 when they had ~50k employees. Perforce monorepo worked pretty well for them until then. It has certain costs to scale a monorepo that far - lots of investment into tooling to make it all work, needs dedicated teams. But it can be scaled. And it offers certain benefits that are very difficult to harness in multi-repo setups - ability to reason about and refactor code across entire repo is the biggest one. > I'm sure the Linux kernel has orders of magnitude more developers than a typical video game or engine Linux kernel development is very different, decentralized across many different companies and ICs, hence the need for DVCS systems like git. In a corporate environment like google or gamedev, it is much easier to keep version control centralized and dedicate a team to maintaining it.
- CivBase 5y ago
  Right. I just wanted to point out that centralized and distributed version control are both designed to scale, just in different ways.