Dev experience at Google kinda sucks for the most part, but one thing that works amazingly well is VCS. You never even have to think about it, it literally just works, and it works at very large scale (monorepo for all of Google).
It’s just: 1. Create a workspace 2. Submit the changes in your workspace
And that’s it. I hate going back to the mess that is Git.
Google's primary internal VCS was originally Perforce (https://www.perforce.com/) and when rewritten to scale to the size of their monorepo largely retained the same user experience. You can read about that here: https://cacm.acm.org/magazines/2016/7/204032-why-google-stor.... Perforce's user experience isn't too different from svn. It is easy because it is a simpler model, and was available from Perforce as far back as the 1990s. You simply can't get into the same kinds of quagmires that git allows you to get into. It is also not a DVCS, which simplifies a lot of issues.
That said, Google's internal Perforce clone doesn't offer any sort of stack/queue of local commits that you can send off for review and continue building on. You've got one copy of your edits and that copy is not under any real version control. For a company that highly prizes code review there was always a tension between sending small-enough changes off for review and continuing to make progress on a larger feature. At the time I left a few years ago there was a staffed project building a Mercurial layer on top of the monorepo VCS that allowed for DVCS-like workflows, such as a local patch queue with multiple dependent changes out for review simultaneously. That little bit of exposure to Mercurial was enough for me to realize that being a DVCS doesn't necessarily require exposure to all the "bare metal" paper cuts that git exposes you to.