Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advantages of monolithic version control

danluu.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: Advantages of monolithic version control

#111

Post by Goladus »

jayd16 wrote: post #77
tzs wrote: post #19

> With a monorepo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies. This is the major thing I miss about Subversion, and the fact that in Subversion a subdirectory in a repository can be checked…

You can get all this functionality with git, gitlab and looking through the consolidated activity page, no?

Perhaps although this sort of reinforces the point that the design of git tends to encourage creating a lot of individual, single-purpose repositories, leaving it up to the user to string them all together with gitlab or github or a custom server, if that's what you want.

I'm not saying I prefer the subversion architecture, but with subversion the pattern described is quite natural and requires no additional technology or design beyond a directory structure.

Re: Advantages of monolithic version control

#113

Post by jameshart »

stcredzero wrote: post #5
nextos wrote: post #3

I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. In the open source world, I have found some Unix distros use the same model. I know it's not as extreme, but the principle is quite similar. For example, in Nixpkgs all package definitio…

I initially found the idea of monolithic repositories hard to digest. But now I think it's a good idea for some of the reasons outlined in the article. Namely, it's very easy to depend on other code that the organization has created. I remember the days when monorepo was the norm, and distributed version control was the weird, kooky idea. Mainstream programmers had knee-jerk notions that all managed environments were…

Do you really mean a monorepo, though, or just a project repo whose scope is one entire game? Because a monorepo for multiple games - including released and in progress ones - seems likely to create a lot of pain in the long term. The release cycle for games seems much more suited to a release branch model, which would kind of require per-game repositories, and some sort of package versioning for common dependencies. I guess maybe with things like mobile games where you have a constantly moving target platform even ‘released’ games are live code so maybe I’m just betraying an outdated ‘gold master’ kind of mindset here?

Re: Advantages of monolithic version control

#114

Post by samkellett »

caurusapulus wrote: post #100
iandanforth wrote: post #9

I didn't notice a link to "Software Engineering at Google" which is a great article that goes into the monorepo argument as well as a lot of other cool practices. https://arxiv.org/abs/1702.01715

Even more relevant IMHO is this: Why Google Stores Billions of Lines of Code in a Single Repository https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

wait hang on...

> At Google, we have found, with some investment, the monolithic model of source management can scale successfully to a codebase with more than one billion files, 35 million commits, and thousands of users around the globe.

so each commit adds on average over 28 new files?

Re: Advantages of monolithic version control

#115

Post by perfmode »

peterevans wrote: post #46
hinkley wrote: post #42

Earlier quoted context omitted.

The class of problems I’m talking about are integration issues. Unit tests look good but when you put the pieces together... When the tests that matter cross version control boundaries you pay for it. Whether the costs outweigh the benefits is something you have to think about.

What does your test coverage look like? Perhaps you're missing something there that would have caught that bug? Testing is, of course, no silver bullet. Tests are written by humans, and humans make mistakes—and it's pretty difficult to achieve 100% test coverage in a production system. The goal of testing is to have confidence in the code you've written. Tests often don't need to cross version control boundaries. You…

Locally reasonable decisions can have globally unreasonable effects.

Re: Advantages of monolithic version control

#116

Post by hinkley »

foxhill wrote: post #64
hinkley wrote: post #51

Earlier quoted context omitted.

Does this allow you to file PRs against the repository you have checked out? Or does this only work for read-only use? What about CI? How do you convince TC or Jenkins or Bamboo to do the same thing? If this does do all that, I think this functionality needs some SEO love because this pretty much never comes up when I search for the latest ways to grab part of a repo. All I find are conversations where people are tru…

perhaps you could rename the repo to something else/move it somewhere else, then ln -s the grandchild, if that’s important?

It breaks down if you need more than a couple of them. But I guess hat could go both ways.

A problem we saw with perforce and the clientspec: when people see a directory structure, they forget they don’t have all the bits. They make errors of judgment based on bad info.

Re: Advantages of monolithic version control

#117

Post by mathgladiator »

sandos wrote: post #72
mathgladiator wrote: post #27

Earlier quoted context omitted.

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

It has to be made up. I am with you, that can no be real. There are trolls for everything.

It is so well crafted that it must be rooted in truth... I just... no. No way. This is too much madness...

Re: Advantages of monolithic version control

#118

Post by icc97 »

mathgladiator wrote: post #117
sandos wrote: post #72

Earlier quoted context omitted.

It has to be made up. I am with you, that can no be real. There are trolls for everything.

It is so well crafted that it must be rooted in truth... I just... no. No way. This is too much madness...

Seems interesting that he would put in comment examples that would delete the entire database. Perhaps the guy telling the story is what happened when little Bobby Tables grew up.

Re: Advantages of monolithic version control

#119

Post by joshuamorton »

jedberg wrote: post #44
joshuamorton wrote: post #15

Earlier quoted context omitted.

But I can say the same thing about multiple repos! I've seen more than one company now that has had the same problem: how do they patch atomic cross-repo changes onto their multiple git repos? The reasons for this can vary, but the core problem is always that. As far as I see it, there are two solutions: - Use a monorepo - Create some external database that ties multiple hashes together for use in your ecosystem. Thi…

> how do they patch atomic cross-repo changes onto their multiple git repos If you need atomic cross repo changes, then you're doing multi-repo wrong. You need to have an upgrade path, so that you support both old and new in parallel, so you can upgrade one repo at a time. You'd need that anyway during deployment.

I don't particularly see why you need that during deployment. And maintaining an upgrade path can be very dangerous. Its both a bunch of added complexity, and a very easy way to introduce subtle issues where upgrading is fine and dandy, but where its impossible to revert a breaking change, because the "change" happened over the course of 3-4 commits and so a revert puts you in an invalid situation, so you're forced to rollback entirely instead.

Re: Advantages of monolithic version control

#120

Post by joshuamorton »

humanrebar wrote: post #99
fishywang wrote: post #65

Earlier quoted context omitted.

2 is simple. Import everything you need to depend on into the repo. Google has 3rdparty directory in its mono repo to put them.

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.

Post reply on HN