Advantages of monolithic version control • Hacker News Board

Re: Advantages of monolithic version control

#131

Post by humanrebar » Tue, Feb 13, 2018, 9:44 PM UTC

joshuamorton wrote: post #120

humanrebar wrote: post #99

Earlier quoted context omitted.

That's an approach. Don't know if I'd call it simple. Your monorepo would start looking like an artifact repository at some point, with multiple versions of products. And Google's approach, I'm sure, requires a bit of standardization and tooling investment. It's not clear to me that equivalent conformance and investment in monorepos and a package manager wouldn't work just as well.

>Your monorepo would start looking like an artifact repository at some point, with multiple versions of products. It shouldn't, that's one of the big gains of a monorepo, is that there's only one version of everything. You don't need to version your dependencies within the repo, which means you only need to maintain one version of any external dependency.

I wouldn't call getting every project, internal or external, on the exact same version of every dependency "simple". That's a lot of hand waving around a really hard problem.

Re: Advantages of monolithic version control

#132

Post by joshuamorton » Tue, Feb 13, 2018, 9:55 PM UTC

humanrebar wrote: post #131

joshuamorton wrote: post #120

Earlier quoted context omitted.

>Your monorepo would start looking like an artifact repository at some point, with multiple versions of products. It shouldn't, that's one of the big gains of a monorepo, is that there's only one version of everything. You don't need to version your dependencies within the repo, which means you only need to maintain one version of any external dependency.

I wouldn't call getting every project, internal or external, on the exact same version of every dependency "simple". That's a lot of hand waving around a really hard problem.

Its hard to do if you don't start out that way early on, yes. I don't really think its hard to maintain that state.

With multi-repo environments, btw you still need to do that kind of dependency version management for certain upgrades. Essentially you can desync but you have to occasionally re-sync everything. I na monorepo environment you can just prevent desynchronization.

Re: Advantages of monolithic version control

#133

Post by jonex » Tue, Feb 13, 2018, 10:11 PM UTC

mathgladiator wrote: post #27

tdumitrescu wrote: post #20

Earlier quoted context omitted.

That sweet abuse of version control reminds me of the fabled JDSL from http://thedailywtf.com/articles/the-inner-json-effect

That can't be real... is it? No. No way.

TDWTF started modifying their stories significantly to avoid people getting in trouble due to telling the stories. Sadly this was used as an opportunity to significantly embellish the stories to the extent that often the major weird thing told about is all made up.

Re: Advantages of monolithic version control

#134

Post by beagle3 » Tue, Feb 13, 2018, 10:38 PM UTC

shados wrote: post #17

I always find it a bit funny how monorepos are now this big exotic new age thing. "Monorepos are the future!". That very well may be, but I think we're at a point where the majority of developers started after git came out (since the industry experienced explosive growth just in the last few years). They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to. The tooling to do…

> They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to.

That was never ever the case. We did centralized repos because we had to, but every single place I worked at, whether they were using SCCS, RCS, CVS, SourceSafe or SVN, had multiple repositories for different projects. No place had more than 20 repos, but then, the largest of those was about 250 people with VCS access.

Re: Advantages of monolithic version control

#135

Post by TheCoelacanth » Wed, Feb 14, 2018, 2:56 AM UTC

humanrebar wrote: post #131

joshuamorton wrote: post #120

Earlier quoted context omitted.

>Your monorepo would start looking like an artifact repository at some point, with multiple versions of products. It shouldn't, that's one of the big gains of a monorepo, is that there's only one version of everything. You don't need to version your dependencies within the repo, which means you only need to maintain one version of any external dependency.

I wouldn't call getting every project, internal or external, on the exact same version of every dependency "simple". That's a lot of hand waving around a really hard problem.

It's a hard problem, but it's not necessarily harder than other approaches to dependency management. There's pretty much no approach to dependency management that isn't hard in one way or another.

Re: Advantages of monolithic version control

#136

Post by shados » Wed, Feb 14, 2018, 3:30 AM UTC

joshuamorton wrote: post #22

shados wrote: post #18

Earlier quoted context omitted.

Eventual consistency. The great thing about multi repo is the ease of decoupling the pieces so they can evolves separately (you can do that in monorepos too, but it's not quite as natural). You're free to PR changes gradually, making sure things work a couple of repos at a time, until you eventually get everything. If you can tolerate temporary inconsistencies, it allows you to scale to infinity, essentially for free…

>Eventual consistency. The great thing about multi repo is the ease of decoupling the pieces so they can evolves separately (you can do that in monorepos too, but it's not quite as natural). 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 si…

> 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 anyone else. Right there is a big win. Dependencies can have multiple versions and the leaf can depend on whichever version they want at any given time. You can do the same thing in a monorepo if everything is in independant folders, but that's just the worse of both worlds.

> you define an adaptor that you slowly migrate everyone onto

No no. The way we do it is: make breaking change, people upgrade to it whenever (with gentle pushes so that we're eventually all on the same version sooner than later). No adapter, no transient state within a service. Just upgrade repos one by one until you got them all, no magic involved. This assumes that your repos represent loosely coupled components (micro services or micro apps).

Re: Advantages of monolithic version control

#137

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

Too wrote: post #48

shados wrote: post #18

Earlier quoted context omitted.

Eventual consistency. The great thing about multi repo is the ease of decoupling the pieces so they can evolves separately (you can do that in monorepos too, but it's not quite as natural). You're free to PR changes gradually, making sure things work a couple of repos at a time, until you eventually get everything. If you can tolerate temporary inconsistencies, it allows you to scale to infinity, essentially for free…

Developers are way to lazy for this to work in practice. Imagine every second commit you make has to be backwards compatible, that for sure is a great way to effectively stop any refactoring of your code base, unless all your interfaces are already perfect and very fixed and you find this a feature. Or people will not care about partial cross repo dependencies resulting in randomly broken builds for others during a s…

> Imagine every second commit you make has to be backwards compatible

No. The whole point is that they don't have to think about it. Aside for micro services used machine to machine with breaking changes that cannot exist in parallel, the point is that they don't have to worry about this. Do whatever you want, other projects do whatever the hell they want, and we just slowly go toward consistency as it becomes convenient until everyone's the same. Repeat. I can upgrade a dependency with a breaking change to my repo. The other team isn't ready yet so they keep using the old version (which works) until they are.

Re: Advantages of monolithic version control

#138

Post by shados » Wed, Feb 14, 2018, 3:37 AM UTC

imiric wrote: post #60

shados wrote: post #18

Earlier quoted context omitted.

Eventual consistency. The great thing about multi repo is the ease of decoupling the pieces so they can evolves separately (you can do that in monorepos too, but it's not quite as natural). You're free to PR changes gradually, making sure things work a couple of repos at a time, until you eventually get everything. If you can tolerate temporary inconsistencies, it allows you to scale to infinity, essentially for free…

This is great in theory, but it requires _a lot_ of discipline and responsibility around dependency management from the developers. What ends up happening in practice is that all these seemingly independent components have very strict—and sometimes even unspecified—dependencies between each other. People create "base" packages that all other packages have a strict or loose dependency on, so when that package changes,…

> This is great in theory, but it requires _a lot_ of discipline and responsibility around dependency management from the developers.

Why? Again, the point is eventual consistency. If I make a breaking change, apps/services that are ready to migrate do so. The ones that aren't keep using the old version. Eventually, everyone's on the same page. The whole point is that it requires a lot less discipline.

Re: Advantages of monolithic version control

#139

Post by shados » Wed, Feb 14, 2018, 3:42 AM UTC

beagle3 wrote: post #134

shados wrote: post #17

I always find it a bit funny how monorepos are now this big exotic new age thing. "Monorepos are the future!". That very well may be, but I think we're at a point where the majority of developers started after git came out (since the industry experienced explosive growth just in the last few years). They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to. The tooling to do…

> They kind of forget (or didn't know) that it's not that long ago we did monorepos because we HAD to. That was never ever the case. We did centralized repos because we had to, but every single place I worked at, whether they were using SCCS, RCS, CVS, SourceSafe or SVN, had multiple repositories for different projects. No place had more than 20 repos, but then, the largest of those was about 250 people with VCS acce…

Most places I worked at had everything in one repo and folders for projects /shrugs. Though some did have multiple repos, though in my book, that's just "many monorepos". 20 repos for 250 people was quite manageable with old tools. When one system is split in 4000 repos, that's a different story.

Re: Advantages of monolithic version control

#140

Post by joshuamorton » Wed, Feb 14, 2018, 4:21 AM UTC

shados wrote: post #136

joshuamorton wrote: post #22

Earlier quoted context omitted.

>Eventual consistency. The great thing about multi repo is the ease of decoupling the pieces so they can evolves separately (you can do that in monorepos too, but it's not quite as natural). 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 si…

> 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 to wait weeks to upgrade in the worst case.