6 ms·

Google's mono-repo is interesting though, in that you can check out individual directories without having to check out the entire repo. It's very different from

by chias 9y ago

Google's mono-repo is interesting though, in that you can check out individual directories without having to check out the entire repo. It's very different from checking out a bajillion-line git repo.

jsolson 9y ago
While technically true due to some features of tooling, that is really only masking off part of the repo under a READ-ONLY directory. Builds can (and usually do) depend on things that aren't part of your local checkout. I'd say CitC is a much more accurate representation of the way Piper and blaze "expect" things to work.
- netheril96 9y ago
  The dependencies are still downloaded only on need though.
  - joshuamorton 9y ago
    The dependencies aren't really "downloaded" at all. When you build something, the artifacts are cached locally, but the files you are editing generally speaking not actually stored on your machine. They're accessed on demand via FUSE.
vvanders 9y ago
That's pretty common feature in most non-DCVS. It was nice having Perforce on the last game I worked on. The art directory was ~500GB and not fun to pull down even with a P4 proxy.
nerfhammer 9y ago
It's kind of interesting that nowadays people assume that version control system == git. For a huge, non-open codebase there are some pretty large downsides to a fully distributed VCS in exchange for relatively few benefits.
- hossbeast 9y ago
  Such as? Then why has everyone switched to git? (Hint, because it is fundamentally built on more powerful ideas than what came before it)
  - emodendroket 9y ago
    Well clearly not "everyone" has since we're apparently talking about a company that hasn't.
  - joshuamorton 9y ago
    Open source has moved to git, mostly because being standardized on one vcs made it easier for people to contribute. A lot of companies don't use git.
    - davidgay 9y ago
      No, before git the standard was svn, and before that, cvs. The switches happened even though there was an existing standard.
      - progre 9y ago
        Having worked with all three, nothing but Stockholm syndrome would keep anyone to switch from cvs. Likevise the switch to git for open source happend (In my opinion) in large part because Github offers a far better experience than SourceForge witch was dominant at the time.
        boulos 9y ago
        There was actually a brief period where Google Code was ascendant, but then GitHub was demonstrably investing more in collaboration. I think one aspect of Git that is really important is forking, and having your own local commits. Merging commits and patches in svn were awful. You wouldn't ever allow someone random to join your svn repo, but if they can reasonably provide a patch, you could take it. Git makes that massively easier.
srj 9y ago
This used to be done manually via "gcheckout" but that's long since been replaced. Users now don't do anything but create quick throwaway clients that have the entire repo in view. Until very recently there was a versioning system for core libraries so those wouldn't typically be at HEAD (minimizing global breakage). Even that has been eliminated now and it's truly just the presubmit checks and code review process that keeps things sane.
- jedmeyers 9y ago
  > truly just the presubmit checks and code review process that keeps things sane. also rollbacks :)
exclusiv 9y ago
Yeah that was what was nice about SVN. You could check out paths.
Too 9y ago
Microsoft is solving this for git with their GVFS. Another issue with git monorepos is access control, does anyone know of good solutions for this, does GVFS solve this also?
paganel 9y ago
> Google's mono-repo is interesting though, in that you can check out individual directories The same is true of svn, which many people like to bash nowadays, even in this discussion.

by chias 9y ago

jsolson 9y ago

While technically true due to some features of tooling, that is really only masking off part of the repo under a READ-ONLY directory. Builds can (and usually do) depend on things that aren't part of your local checkout. I'd say CitC is a much more accurate representation of the way Piper and blaze "expect" things to work.

netheril96 9y ago
The dependencies are still downloaded only on need though.
- joshuamorton 9y ago
  The dependencies aren't really "downloaded" at all. When you build something, the artifacts are cached locally, but the files you are editing generally speaking not actually stored on your machine. They're accessed on demand via FUSE.

vvanders 9y ago

That's pretty common feature in most non-DCVS. It was nice having Perforce on the last game I worked on. The art directory was ~500GB and not fun to pull down even with a P4 proxy.

nerfhammer 9y ago

It's kind of interesting that nowadays people assume that version control system == git. For a huge, non-open codebase there are some pretty large downsides to a fully distributed VCS in exchange for relatively few benefits.

hossbeast 9y ago
Such as? Then why has everyone switched to git? (Hint, because it is fundamentally built on more powerful ideas than what came before it)
- emodendroket 9y ago
  Well clearly not "everyone" has since we're apparently talking about a company that hasn't.
- joshuamorton 9y ago
  Open source has moved to git, mostly because being standardized on one vcs made it easier for people to contribute. A lot of companies don't use git.
  - davidgay 9y ago
    No, before git the standard was svn, and before that, cvs. The switches happened even though there was an existing standard.
    - progre 9y ago
      Having worked with all three, nothing but Stockholm syndrome would keep anyone to switch from cvs. Likevise the switch to git for open source happend (In my opinion) in large part because Github offers a far better experience than SourceForge witch was dominant at the time.
      - boulos 9y ago
        There was actually a brief period where Google Code was ascendant, but then GitHub was demonstrably investing more in collaboration. I think one aspect of Git that is really important is forking, and having your own local commits. Merging commits and patches in svn were awful. You wouldn't ever allow someone random to join your svn repo, but if they can reasonably provide a patch, you could take it. Git makes that massively easier.

srj 9y ago

This used to be done manually via "gcheckout" but that's long since been replaced. Users now don't do anything but create quick throwaway clients that have the entire repo in view. Until very recently there was a versioning system for core libraries so those wouldn't typically be at HEAD (minimizing global breakage). Even that has been eliminated now and it's truly just the presubmit checks and code review process that keeps things sane.

jedmeyers 9y ago
> truly just the presubmit checks and code review process that keeps things sane. also rollbacks :)

exclusiv 9y ago

Yeah that was what was nice about SVN. You could check out paths.

Too 9y ago

Microsoft is solving this for git with their GVFS. Another issue with git monorepos is access control, does anyone know of good solutions for this, does GVFS solve this also?

paganel 9y ago

> Google's mono-repo is interesting though, in that you can check out individual directories The same is true of svn, which many people like to bash nowadays, even in this discussion.