Live data from Hacker News

Why Google Stores Billions of Lines of Code in a Single Repository (2016)

cacm.acm.org

291–293 of 293 posts

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#291
post #256

Earlier quoted context omitted.

BSDs simply don't guarantee ABI stability, so no third party app should ever make a syscall directly. It all goes via libc. So, yes, from that perspective, it is a fully self-contained system. In practice, third-party apps sometimes think that they know better, and get broken. Anything written in Go, for example: https://github.com/golang/go/issues/16272

Sure they do guarantee the ABI stability (within major release), but the main thing here is that FreeBSD - like pretty much any other operating system, but differently from Linux - maintains the stability at the libc level, not at syscall level.

I meant kernel ABI specifically, of course.

And it's a guarantee that is, essentially, useless for any purpose other than the interaction between the base system and the kernel - i.e. not for third party software.

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#292
post #107
post #87

Earlier quoted context omitted.

It took me a while to figure out that you're disagreeing with me, because your last paragraph is a perfect example of why monorepos are so dangerous. Imagine a tooling team on a different continent that makes some changes this afternoon. Like you said, their intent is just to add a new option, and it ought to have no extensional changes in behavior, but it still ends up behaving subtly different. The next morning, al…

> In a versioned world, you can still freeze your dependency at 1.324.5234, and migrate only when you want to, and when you're feeling confident about it. The correct course of action is to either reverse/fix the code change to the library you depend on, or if your code is clearly using the library wrong and can be easily fixed, to do that. Not to let the whole ecosystem slowly spiral out of control. Either way, the…

>> In a monorepo world, you don't have a choice. You've been forcefully migrated

> Yes, and that's good

In your projects, have you configured your build system to always auto-pull the latest version of every single dependency you have? If not, you're not practicing what you've claimed above.

FWIW, java-maven used to allow specifying LATEST/RELEASE versions, so that the latest version will always be auto-pulled on every build. They later removed that option entirely, because they realized how dangerous that is.

https://stackoverflow.com/questions/30571/how-do-i-tell-mave...

Re: Why Google Stores Billions of Lines of Code in a Single Repository (2016)

#293

Earlier quoted context omitted.

This currently only works on Windows, although they are planning OSX and Linux ports.

That is important. My link was back in 2017. Do you know of any ETA for GVFS getting on Linux?

I went to a talk earlier this year where they said they would do OSX before Linux. So it may be some time. There are design complexities in getting it to work, Windows has quite a different structure for filesystem drivers.
Post reply on HN