Advantages of monolithic version control • Hacker News Board

Re: Advantages of monolithic version control

#141

Post by shados » Wed, Feb 14, 2018, 4:35 AM UTC

joshuamorton wrote: post #140

shados wrote: post #136

Earlier quoted context omitted.

> I don't see how you can do this any better in a multi-repo than a monorepo though, unless you mean to the extent of simultaneously having multiple versions of the same library in your transitive deps (and thus kind of kludgily sidestepping the diamond dependency issues). Would you mind elaborating? Leaf repos (projects nothing depends on, like apps) can do literally whatever they want at any time without affecting…

These two things you state only work if you have no shared deps. If I depend on A and B, and B also depends on A, I can't use whatever version of A I want, it has to be compatible with B. This means that I'm forced to delay my upgrade of A until B has done so. There longer the chain of deps is the worse this is. Even if everyone takes just couple days to upgrade, which ime is generous, your leaves end up being forced…

Depends: if B declares that it is compatible with both versions of A (because it uses methods that did not break), then you sure can upgrade whenever you want (and potentially start using new methods that contained breaking change).

If the change is breaking for B, then yeah, you have to wait until B upgrades (or you can upgrade it yourself!). During that time, other projects that don't depend on B can go on using the new A.

The alternative is "stop the press, everyone is upgrading to the latest A NOOOOOOOOOW", which if the change is not automatable, might either be non-realistic, be pretty large in scope, or require you to never make drastic changes in A (which is tricky if A is a 3rd party you don't control). You can also just have these long-running transient state where somehow A is always compatible with everything no matter via compatibility wrappers.

It's tradeoffs. I like our world where we don't have to migrate everything at the same time all the time, even with drastic changes. Works quite well for us, with thousands of repos and 10s of millions of lines of code. We enjoy the flexibility. It makes certain cross-project efforts harder. That's the tradeoff.

Re: Advantages of monolithic version control

#142

Post by mnm1 » Wed, Feb 14, 2018, 8:43 AM UTC

peterevans wrote: post #25

mnm1 wrote: post #23

Earlier quoted context omitted.

With multiple repos, how do you solve the issue that the private dependencies installed by package managers are not themselves under source control when you edit them? They are in /vendor or /node_modules or whatever. It's easy to pull them down and of course, for other people's dependencies, this is fine. But say I pull out one component of my app that's used by multiple apps. I set up my private repo or maybe the p…

Any changes you need to make to internal libraries you install via package manager would need to be made to those separate repositories that house the libraries, and then those changes would have a release made (generally this is done through a git tag, and using semantic versioning). Once you update the version, your package manager will allow you to install that update to the other places you're using it, so all yo…

No, semantic versioning and package management is really not a sane way to manage development. You're saying every time I make a code change, I should release a patch version BEFORE I can even test it, since I cannot test that dependency by itself. I'm sorry, but that's just insane, not to mention time consuming. And yes, my libraries are used by multiple apps. Why else would I need to split them out as dependencies? Actually, after thinking through this, the only solution I can think of is symlinks and those would work with a monorepo or multiple repos just as well.

Re: Advantages of monolithic version control

#143

Post by uiri » Wed, Feb 14, 2018, 4:50 PM UTC

amag wrote: post #130

uiri wrote: post #41

Earlier quoted context omitted.

Microsoft doesn't really use a monorepo (although they may have done so in the past). Everything is moving to git, and while they've invested significant effort into getting git to handle larger repos, you don't have everything living in one repo quite the same way that Google does it. My understanding of Google's monorepo is that search, mail, maps, etc. all live inside one repo.

Uh, they moved all of Windows into a single git-repo. It used to sprawl over 40+ Source Depot repos but now it's one gigantic monorepo [1]. [1] https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g...

Right, but Office, SQL Server and Azure don't live beside it in the same repo. Windows is one project. The FreeBSD base system lives in one repository but I wouldn't call it a monorepo.

Re: Advantages of monolithic version control

#144

Post by peterevans » Thu, Feb 15, 2018, 1:21 AM UTC

mnm1 wrote: post #142

peterevans wrote: post #25

Earlier quoted context omitted.

Any changes you need to make to internal libraries you install via package manager would need to be made to those separate repositories that house the libraries, and then those changes would have a release made (generally this is done through a git tag, and using semantic versioning). Once you update the version, your package manager will allow you to install that update to the other places you're using it, so all yo…

No, semantic versioning and package management is really not a sane way to manage development. You're saying every time I make a code change, I should release a patch version BEFORE I can even test it, since I cannot test that dependency by itself. I'm sorry, but that's just insane, not to mention time consuming. And yes, my libraries are used by multiple apps. Why else would I need to split them out as dependencies?…

Sorry—I just saw this! But, as it was, I was not saying that you should release a patch version every time you make a code change. That would indeed be pretty arduous!

What you should do is test your library independently from the consumer that uses it. If that's not possible, ask yourself why that is; maybe this code should not be sequestered into a library after all, or maybe it needs to be designed a bit differently to remove some of the coupling between the library and app that seems to be at issue.

Ideally, your testing in your app should not be testing that the library works; it should be testing that your use of the library works. Too bad the real world is much messier than the ideal world.

Good luck either way!