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

121–130 of 144 posts

Re: Advantages of monolithic version control

#121

Post by jedberg »

stormbrew wrote: post #66
jedberg wrote: post #12

The catch is the tooling. If you have the time and resources to make the tooling that is necessary to make it work specifically for your org, than great! But if you don't, then a monorepo will generally slow you down because it will require coordinating changes across a much bigger group of people. Monorepos are great for very small companies with a low communication overhead, and very large companies with the resour…

It will slow you down because you're forced to confront the consequences of your change in real time, not down the road when someone notices something changed somewhere else that may or may not have broken their invariants in ways they now have to figure out. Tooling isn't the issue here, you're basically arguing for kicking the can down the road and encouraging a buildup of technical debt.

That's not true at all.

When you write code, do you put everything into a single function, or do you use separate functions for different parts of the code? Multi-repo is just the extension of that.

Software quality is orthogonal to your development methods. You can have good quality multi-repos or bad ones, and you can have good quality mono-repos, or bad ones.

Re: Advantages of monolithic version control

#122

Post by connorshea »

9034725985 wrote: post #91

Here is a naive question: Let's say I want a small application with flask and angular. I create a single repo for both flask and angular. I put everything flask in one sub folder called backbend and I put everything angular in another folder called frontend WIP here: https://github.com/kusl/flaskexperiment or https://git.sr.ht/%7Ekus/flaskexperiment/ Now the problems are just starting: how do I set up ci for all my p…

Not Sid, but thanks for being a fan ;)

Re: Advantages of monolithic version control

#123

Post by connorshea »

skovorodkin wrote: post #95
9034725985 wrote: post #91

Here is a naive question: Let's say I want a small application with flask and angular. I create a single repo for both flask and angular. I put everything flask in one sub folder called backbend and I put everything angular in another folder called frontend WIP here: https://github.com/kusl/flaskexperiment or https://git.sr.ht/%7Ekus/flaskexperiment/ Now the problems are just starting: how do I set up ci for all my p…

> Travis ci expects a single file at the root of the project and so does gitlab ci GitLab has a related issue to support "Several .gitlab-ci.yml for monorepos" ( https://gitlab.com/gitlab-org/gitlab-ce/issues/18157 ).

We also have an issue for running jobs only when modifications are made to a given file or files in a directory, it's tentatively scheduled for 10.7 (April's release).

https://gitlab.com/gitlab-org/gitlab-ce/issues/19232

Re: Advantages of monolithic version control

#124

Post by icebraining »

Goladus wrote: post #111
jayd16 wrote: post #77

Earlier quoted context omitted.

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 technolo…

the design of git tends to encourage creating a lot of individual, single-purpose repositories

Which is weird, considering it was designed to be used as the Linux repository control system, which is a monolithic repo.

Re: Advantages of monolithic version control

#125

Post by icebraining »

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…

I've heard people longing for this, but unless you have huge binary assets, what's the point?

When he checks the history in either of those, he only sees commits that affected those directories or their subdirectories.

And in git, you just enter the directory and do "git log ."

Re: Advantages of monolithic version control

#126

Post by mercer »

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.

It strikes me as /r/nosleep but for IT.

Re: Advantages of monolithic version control

#127

Post by icebraining »

mnm1 wrote: post #23
peterevans wrote: post #13

Using multiple repositories seems like the most natural workflow to have. It's easy to make a new one; it's lightweight to do, and it allows your code base to scale naturally. You can set permissions for each repository, so if you did include some sensitive code within one repository or another, it's easy to narrow the access to them. (Yes, don't include sensitive code in a repository—but in an early-stage company, y…

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…

We used git submodules. The "app" repo didn't contain any code, just configuration and the submodules, which are essentially links to other repos (the app modules, in this case). Those libraries could be freely linked from multiple apps, of course.

Disadvantage: it's not a package manager; it doesn't read all the dependencies from each library, resolve the duplicates and install them centrally. Instead of that, we only had submodules in the top repo (the app) - a bit like having a single requirements.txt file.

Re: Advantages of monolithic version control

#128

Post by icebraining »

samkellett wrote: post #114
caurusapulus wrote: post #100

Earlier quoted context omitted.

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?

There are probably commits that add hundreds or thousands of auto-generated files, raising the average.

Also, it depends on how much you squash - my latest 10 commits turned into just one when merging to master.

Re: Advantages of monolithic version control

#129

Post by stormbrew »

jedberg wrote: post #121
stormbrew wrote: post #66

Earlier quoted context omitted.

It will slow you down because you're forced to confront the consequences of your change in real time, not down the road when someone notices something changed somewhere else that may or may not have broken their invariants in ways they now have to figure out. Tooling isn't the issue here, you're basically arguing for kicking the can down the road and encouraging a buildup of technical debt.

That's not true at all. When you write code, do you put everything into a single function, or do you use separate functions for different parts of the code? Multi-repo is just the extension of that. Software quality is orthogonal to your development methods. You can have good quality multi-repos or bad ones, and you can have good quality mono-repos, or bad ones.

When I write two functions in the same project I get a compile error if I change the signature of one without changing the call site. This is analogous to a monorepo, in which I have projects in separate directories but with a unified build.

If you really want to take this analogy to its logical conclusion for separate repos, you're gonna have to do something more like compile every function as a dynamically loaded library. And then hope you notice a function signature change because the dynamic linker won't tell you.

Re: Advantages of monolithic version control

#130

Post by amag »

uiri wrote: post #41
amag wrote: post #6

On the other end of the spectrum, a colleague of mine recently told me about when his previous company (big, 100k+ employees) were starting to adopt git, some people seriously considered having a separate repository per file ! "Because then you can just set up your project as using version X of file A and version Y of file B" It's good we now have (at least) Google, Facebook and Microsoft as examples of companies usi…

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

Post reply on HN