[HN Gopher] Monorepos and Forced Migrations ___________________________________________________________________ Monorepos and Forced Migrations Author : zdw Score : 17 points Date : 2021-10-12 21:58 UTC (1 hours ago) (HTM) web link (buttondown.email) (TXT) w3m dump (buttondown.email) | joshuamorton wrote: | 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". | | Lest, by the way, you think I'm ignoring very real issues, I | should note that my entire job for the last year and for the | foreseeable future is managing an infrastructure migration around | a set of mandates that involves fitting some square pegs into | round holes. | | [1]: https://news.ycombinator.com/item?id=28825352 | | [2]: | https://opensource.google/docs/thirdparty/oneversion/#tempor... | xeorfuzzion wrote: | I thought google hasn't use perforce for years but something | called piper[1]. Aren't migrations good on some aspects such as | force engineers to stop using insecure libraries? I would say you | could do internal migrations without having to change external | apis, maybe google should care about the customer more? or is | there some other reason for these external forced migrations? | | [1]https://research.google/pubs/pub45424/ | dietr1ch wrote: | > I thought google hasn't use perforce for years but something | called piper[1]. | | Yes, but for I guess the author wanted to keep things simple | for outsiders. | | Piper is supposedly not much different than Perforce. | Forgetting implementation details is just a centralized version | control system that holds a monorepo and everyone* just test | and build from trunk/master/head. | Normal_gaussian wrote: | > Aren't migrations good on some aspects such as force | engineers to stop using insecure libraries? | | Sure, but how many times have you deployed an update that you | were sure was security? Most libs I work with are 90+% features | or ease-of-use releases, the security is hand wavy to do with | dependencies, or a very rare "oops". | mattnewton wrote: | This is mitigated somewhat by having integration tests (which | shine in migration-like situations like this despite their | other problems). | dekhn wrote: | that's correct, the monorepo stopped being served by perforce | many years ago (the efforts to keep it scaling were heroic). | Instead, google made something which appears to be API- | compatible with perforce (so the tooling continued to work) but | is backed by Google technologies with the source hosted in the | datacenters (which is kind of a circular situation). ___________________________________________________________________ (page generated 2021-10-12 23:00 UTC)