4 ms·

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

by woah 12y ago

dpark 12y ago
No, it's something that Perforce allows (because it scales sufficiently). It has nothing to do with C++. You can impose order within the monolithic repo by partitioning projects into their own branches or directories and only pulling down the necessary pieces. Whether this is better than a bunch of small repos is debateable.
- nevir 12y ago
  Perforce (the product) doesn't really scale sufficiently for the Googles/Amazons/Microsofts of the world, sadly. I think they've all moved to custom forks/implementations due to the insane SPOF that Perforce servers are (and their hardware requirements). But up til that point, heck yeah!
  - deleted 12y ago
    [deleted]
  - dpark 12y ago
    Well, Perforce in its default state may not scale sufficiently, but at least two of the companies on that list have managed to make it work (presumably with a lot of investment, though). :) I didn't know Amazon was using Perforce. I interviewed someone from Amazon recently and he indicated they were on Git for most things now.
    - gagomes 12y ago
      Amazon has phased out perforce a year ago. There is very little left, most repositories (perforce, svn, etc) were migrated to git repositories.
nevir 12y ago
Just philosophical. I'm honestly not sure which approach I like more after having done it both ways: highly isolated projects (open source world, at Amazon), and monolithic (at Google). It all boils down to dependency management in the end. --- For the monolithic world: * You're always developing against the latest version of your dependencies (or very near it). * This comes at the cost of a continuous, but minimal, maintenance burden as upstream folk make changes. * * However, because things are monolithic, upstream projects can change _your_ code, as well. You can be confident that you know exactly who is affected by your API change. * * Similarly, being able to make an API change and run the tests of _everyone that depends on you_ is a huge benefit. * You have to be more diligent when testing things that go out to users, as your code is constantly evolving. --- For the isolated world: * You can develop without fear of interruptions; your dependencies are pinned to specific versions. * You get to choose when to pay the cost of upgrading dependencies (but typically, the cost is pretty high, and risks introducing bugs). * * Security patches can be particularly annoying to manage, though (if you let your dependencies drift too far from current) * During deployment, you can be extremely confident about the bits that go out. * You can get away with less rigorous infrastructure (and maintenance costs related to that)

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

by woah 12y ago

Yea what's up with that? Sounds like a pretty terrible practice to me. Is that something that c++ forces you to do?

dpark 12y ago

No, it's something that Perforce allows (because it scales sufficiently). It has nothing to do with C++. You can impose order within the monolithic repo by partitioning projects into their own branches or directories and only pulling down the necessary pieces. Whether this is better than a bunch of small repos is debateable.

nevir 12y ago
Perforce (the product) doesn't really scale sufficiently for the Googles/Amazons/Microsofts of the world, sadly. I think they've all moved to custom forks/implementations due to the insane SPOF that Perforce servers are (and their hardware requirements). But up til that point, heck yeah!
- deleted 12y ago
  [deleted]
- dpark 12y ago
  Well, Perforce in its default state may not scale sufficiently, but at least two of the companies on that list have managed to make it work (presumably with a lot of investment, though). :) I didn't know Amazon was using Perforce. I interviewed someone from Amazon recently and he indicated they were on Git for most things now.
  - gagomes 12y ago
    Amazon has phased out perforce a year ago. There is very little left, most repositories (perforce, svn, etc) were migrated to git repositories.

nevir 12y ago

Just philosophical. I'm honestly not sure which approach I like more after having done it both ways: highly isolated projects (open source world, at Amazon), and monolithic (at Google). It all boils down to dependency management in the end. --- For the monolithic world: * You're always developing against the latest version of your dependencies (or very near it). * This comes at the cost of a continuous, but minimal, maintenance burden as upstream folk make changes. * * However, because things are monolithic, upstream projects can change _your_ code, as well. You can be confident that you know exactly who is affected by your API change. * * Similarly, being able to make an API change and run the tests of _everyone that depends on you_ is a huge benefit. * You have to be more diligent when testing things that go out to users, as your code is constantly evolving. --- For the isolated world: * You can develop without fear of interruptions; your dependencies are pinned to specific versions. * You get to choose when to pay the cost of upgrading dependencies (but typically, the cost is pretty high, and risks introducing bugs). * * Security patches can be particularly annoying to manage, though (if you let your dependencies drift too far from current) * During deployment, you can be extremely confident about the bits that go out. * You can get away with less rigorous infrastructure (and maintenance costs related to that)