[mattarm]

I wouldn't say Google's VCS solves all problems. I worked there for years and was constantly looking toward git (or something like it) as a way of managing code I was developing before committing it to the monorepo.

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.

[brap]

I never really missed it. If you need it, you can always patch your workspace with edits from another workspace while it’s being reviewed. Or multiple workspaces.