Hacker News Reader

Comment by joneholland | Hacker News Reader

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.

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

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-sto...

(note: I work at Google and absolutely love our SCM and other dev tooling)

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.

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".

I agree, which is also why I think monorepos are an anti pattern.

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.

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.

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.

Reply on news.ycombinator.com