3 ms·

This sort of mixes up a number of issues: The whole git/mercurial thing is, as I understand it, related to the extensibility of the systems. Mercurial is hacka

This sort of mixes up a number of issues: The whole git/mercurial thing is, as I understand it, related to the extensibility of the systems. Mercurial is hackable and extensible in ways that matter, git isn't (or at least wasn't) The one version policy only really matters for third party dependencies. If you're making a change to a library that is entirely within the monorepo, you can do a three phase migration (add the new functionality, migrate users, deprecate the old functionality). Google is exceedingly efficient at this, and the vast majority of the time these migrations can be done without any effort by local owners. For third party deps, you can't usually do that, but there's a workaround[2]. I also think that this post and the one here[1] are amusingly both on the front page at the same time. This one decrying the exact sort of mandate based approaches that "make SRE scale". Also worth mentioning that > The person making the new API is expected to change client code to match, but is not responsible for ensuring the change does not break the client. Is just explicitly untrue. There are policies that are clear about this (this generally comes down to "we cannot break your tests, but if it isn't tested, we can't know we broke it") [1]: https://news.ycombinator.com/item?id=28825352 https://news.ycombinator.com/item?id=28825352 [2]: https://opensource.google/docs/thirdparty/oneversion/#temporary-month https://opensource.google/docs/thirdparty/oneversion/#tempor...

dekhn 5y ago
google employed the folks who wrote the git clients and it was always technically possible to have implemented the monorepo with a git client, but one of the developers (the author of jgit) was opposed to this and prevented it from happening (mainly because his requests for headcount were always denied). As the ex-maintainer of numpy and scipy third_party at google, I really appreciated the one-version-policy. It was the only way to sanely handle upgrades of thousands of different codes (and google has thousands of different codes that depend on numpy). It certainly helped us managed the complexity associated with mixing various versions of numerical libraries.
- joshuamorton 5y ago
  > google employed the folks who wrote the git clients and it was always technically possible to have implemented the monorepo with a git client I think we're talking past each other a bit here. Piper's implementation could have been git-compatible originally yes (I think this is what you're saying?). The thing this article complains about is the turndown of the unofficial, unstaffed (20% at best) git-wrapper client around piper. That was a hacky not-fully-git-like but still well loved (I used it for a while!) tool. Doing it right would have been a huge undertaking and, as I understand, would have required building a totally new thing, while mercurial was hackable and extensible and could be used as a base.
  - dekhn 5y ago
    I'm not talking about the git wrapper. I'm talking about native "git talks to piper" support, with sparse (read-through) for parts of the tree that aren't checked out. It wouldn't have been a huge undertaking, that was never the case. It's what's documented, but it wasn't actually truth. I worked with the individuals involved at the time the decisions were made and the rationale was much weaker than you think.
dan-robertson 5y ago
I think it’s possible for two things to be true: - monorepos are a good way to organise software, especially if there are many internal libraries or dependencies - It is bad if your dependencies are always churning and breaking and disappearing underneath you It sounds like the actual problem might be that there are too many dependencies or that they change more frequently. I think the OP was suggesting that the latter of these is the case.
- joshuamorton 5y ago
  I would agree with this for the most part, but I'd also note that I think the case the author describes is uniquely bad and that probably necessitates some investigation. IDK, maybe their org doesn't follow the rules, or maybe the product they're responsible for doesn't have enough unit tests, so breakages can slip through, or maybe their (or my) bullshit radar is tuned badly and one of us is out of touch with how most people experience the churn. (I should also mention that there are recognized issues with the cost of churn at Google, but this isn't really one of them)

dekhn 5y ago

google employed the folks who wrote the git clients and it was always technically possible to have implemented the monorepo with a git client, but one of the developers (the author of jgit) was opposed to this and prevented it from happening (mainly because his requests for headcount were always denied). As the ex-maintainer of numpy and scipy third_party at google, I really appreciated the one-version-policy. It was the only way to sanely handle upgrades of thousands of different codes (and google has thousands of different codes that depend on numpy). It certainly helped us managed the complexity associated with mixing various versions of numerical libraries.

joshuamorton 5y ago
> google employed the folks who wrote the git clients and it was always technically possible to have implemented the monorepo with a git client I think we're talking past each other a bit here. Piper's implementation could have been git-compatible originally yes (I think this is what you're saying?). The thing this article complains about is the turndown of the unofficial, unstaffed (20% at best) git-wrapper client around piper. That was a hacky not-fully-git-like but still well loved (I used it for a while!) tool. Doing it right would have been a huge undertaking and, as I understand, would have required building a totally new thing, while mercurial was hackable and extensible and could be used as a base.
- dekhn 5y ago
  I'm not talking about the git wrapper. I'm talking about native "git talks to piper" support, with sparse (read-through) for parts of the tree that aren't checked out. It wouldn't have been a huge undertaking, that was never the case. It's what's documented, but it wasn't actually truth. I worked with the individuals involved at the time the decisions were made and the rationale was much weaker than you think.

dan-robertson 5y ago

I think it’s possible for two things to be true: - monorepos are a good way to organise software, especially if there are many internal libraries or dependencies - It is bad if your dependencies are always churning and breaking and disappearing underneath you It sounds like the actual problem might be that there are too many dependencies or that they change more frequently. I think the OP was suggesting that the latter of these is the case.

joshuamorton 5y ago
I would agree with this for the most part, but I'd also note that I think the case the author describes is uniquely bad and that probably necessitates some investigation. IDK, maybe their org doesn't follow the rules, or maybe the product they're responsible for doesn't have enough unit tests, so breakages can slip through, or maybe their (or my) bullshit radar is tuned badly and one of us is out of touch with how most people experience the churn. (I should also mention that there are recognized issues with the cost of churn at Google, but this isn't really one of them)