[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)