1. 15
  1.  

  2. 3

    Perforce, which both Google and Microsoft forked their tooling from…

    1. 5

      I thought Microsoft didn’t use P4 anymore though, they developed they own Git extension to be able to support Windows development[1].

      [1] https://devblogs.microsoft.com/bharry/scaling-git-and-some-back-story/

      1. 1

        Neither Microsoft nor Google use P4 anymore. They forked. Later, they both wrote their own SCMs; TFS and Piper, respectively.

      2. 2

        PlasticSCM also looks interesting. I have yet to find someone with practical experience though.

      3. 2

        With multirepo you have an inherent race condition

        Use submodules? They seem pretty atomic to me. Committing submodule updates to the root repo kinda reminds me of ZFS writing the uberblock to the disk :)

        Of course they’re a bit messier than a monorepo, everyone has to agree to sync the submodules etc. but you are able to do these root commits that synchronize the set of projects’ commits that should be used together.

        The Apache Foundation has a big subversion repository

        Yeah, that works because SVN can checkout a subdirectory, so anyone working on a project can checkout just the project as if it were its own repo. I doubt it’s intended as a monorepo — no one needs to do atomic commits of maven and zookeeper changes together :)

        Maybe Google is already building it.

        Uh you already mentioned at the top of the post that

        [Google] eventually developed a custom version control system for that

        :)

        1. 1

          Google building it refers to this merged build-and-version-control. My understanding is that Blaze is separate.

        2. 2

          Excellent write-up.

          I think the other key benefit is in process management/governance relate to the multirepo “explosion of small repos” problem. That’s a process problem generated by a technical design.

          The author’s remark on the fact that it’s not really a small/midsize project problem is onpoint as well. It will probably be either an “open source” qua kubernetes (i.e., essentially big corp sharing IP, but publically), or proprietary.

          ClearCase has some absolutely brilliant ideas, hidden behind years of neglect and designs for the late 80s. :-)

          1. 1

            Fascinating, and it echoes some of my own thoughts but takes them further. The time is coming for a new generation of VCS’s sooner or later, ones with more control over large repos, sparse histories and binary files. Maybe I’ll try making one someday.