5 ms·

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.

nhumrich 10y ago
I would say the bigger the repo becomes (in terms of # of collaborators) the more important trunk based becomes regardless of SCM choice. Mainly because merging many branches for many teams becomes very tedious and hairy. By the time you resolve all the merge conflicts, someone else will commit a merge and you'll have to resolve conflicts all over again.
- joneholland 10y ago
  I agree, which is also why I think monorepos are an anti pattern.
  - hamandcheese 10y ago
    If two teams are working on two parts of an app that could be in different repos then they would have no conflicts while in a monorepo.
- hamandcheese 10y ago
  Wouldn't you have the same problem with trunk though? If you commit at the same time as someone else, and they push their changes first, then you'll have to resolve any conflicts before you push. It seems that trunk based development is merely a means of enforcing extremely short lived "branches".
kyrra 10y ago
Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it. https://m.youtube.com/watch?v=W71BTkUbdqE https://m.youtube.com/watch?v=W71BTkUbdqE
- jsolson 10y ago
  Piper is awesome, but it's not unreasonable to think of it as Perforce if you designed and built Perforce to scale to handling all of Google in one repo. It has basically the same set of nouns and verbs. citc is the really magical bit, UX wise, as it's like you had a Perforce view set up for our entire repo but never actually had to sync it manually. Just navigate to a file and start hacking. The paper that corresponds to the talk includes numbers on that (I forget if they're in the video). http://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext http://m.cacm.acm.org/magazines/2016/7/204032-why-google-sto... (note: I work at Google and absolutely love our SCM and other dev tooling)
dastbe 10y ago
Amazon (today) maintains a git repo per package, though in theory there's no reason why it has to stay git (or even be homogenous). Each application is a set of versioned artifacts that can be updated, forked, or merged together so long as the whole set builds together.
- joneholland 10y ago
  Sounds like they still use Brazil. I've never understood the mono repo argument. With something like Brazil (or even sonatype nexus), you end up in a much stronger place for guaranteeing consistency and immutability in your builds.

In the article it was google (perforce) and Facebook (mercurial with hacks). Both are massive mono repos. At Amazon they were mostly perforce when I was there. Granted that was a few years back.

nhumrich 10y ago

I would say the bigger the repo becomes (in terms of # of collaborators) the more important trunk based becomes regardless of SCM choice. Mainly because merging many branches for many teams becomes very tedious and hairy. By the time you resolve all the merge conflicts, someone else will commit a merge and you'll have to resolve conflicts all over again.

joneholland 10y ago
I agree, which is also why I think monorepos are an anti pattern.
- hamandcheese 10y ago
  If two teams are working on two parts of an app that could be in different repos then they would have no conflicts while in a monorepo.
hamandcheese 10y ago
Wouldn't you have the same problem with trunk though? If you commit at the same time as someone else, and they push their changes first, then you'll have to resolve any conflicts before you push. It seems that trunk based development is merely a means of enforcing extremely short lived "branches".

kyrra 10y ago

Google doesn't use perforce anymore. They have a custom in-house SCM that has various interfaces wrapped around it. I'd recommend this video that describes it. https://m.youtube.com/watch?v=W71BTkUbdqE https://m.youtube.com/watch?v=W71BTkUbdqE

jsolson 10y ago
Piper is awesome, but it's not unreasonable to think of it as Perforce if you designed and built Perforce to scale to handling all of Google in one repo. It has basically the same set of nouns and verbs. citc is the really magical bit, UX wise, as it's like you had a Perforce view set up for our entire repo but never actually had to sync it manually. Just navigate to a file and start hacking. The paper that corresponds to the talk includes numbers on that (I forget if they're in the video). http://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext http://m.cacm.acm.org/magazines/2016/7/204032-why-google-sto... (note: I work at Google and absolutely love our SCM and other dev tooling)

dastbe 10y ago

Amazon (today) maintains a git repo per package, though in theory there's no reason why it has to stay git (or even be homogenous). Each application is a set of versioned artifacts that can be updated, forked, or merged together so long as the whole set builds together.

joneholland 10y ago
Sounds like they still use Brazil. I've never understood the mono repo argument. With something like Brazil (or even sonatype nexus), you end up in a much stronger place for guaranteeing consistency and immutability in your builds.