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

61–70 of 144 posts

Re: Advantages of monolithic version control

#61

Post by chousuke »

StillBored wrote: post #21
chimeracoder wrote: post #11

Earlier quoted context omitted.

> 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" This basically sounds like CVS.

If that is how you were using CVS, its no surprise that it gets so much hate. OTOH, I think the common CVS workflow actually matches the modern "we don't do stable branches" workflow a lot better than git does. Basically, if you had upstream CVS branches for more than released versions of software in maintenance mode you were doing it wrong. I also tend to yearn for the days when I didn't spend 20% of my time rebasin…

> Git is one of those tools that let you endlessly play with your tools rather than getting the job done

I vehemently disagree with this sentiment. In fact, I find the opposite to be true. Git is the first VCS I used that is useful during coding instead of after it, when it's time to publish the final product, ie. a changeset. I can commit, merge, branch, rewrite and share changes freely and effortlessly whenever I need to without committing a bunch of crap to the shared repository that is of no interest to anyone.

After I'm finished getting shit done, I can then spend some time reviewing and thinking about the logical progression of changes so that the commit log will be readable to other people and older me. This is often just as valuable as writing the code itself.

Re: Advantages of monolithic version control

#63

Post by fishywang »

zdw wrote: post #31

The argument against this is that other external-to-Google-but-started-by-Google projects like Golang and Android use the multirepo model, with gerrit. There are pros and cons to each - do you want to have a hugely churning "I always have to rebase/merge" repo under you, or multiple repos and trouble keeping them in sync? Having done both, I'm not sure which is better - it's probably very project specific.

Android uses multirepo model not because they want to, it's because they have to. You can't have a single repo Android's size in git and still run it snappy. All the tools, including the old repo tool and the new toolings around gerrit, are to make the actual multirepo model works like a single repo.

Re: Advantages of monolithic version control

#64

Post by foxhill »

hinkley wrote: post #51
DaiPlusPlus wrote: post #34

Earlier quoted context omitted.

Git supports this scenario as "sparse checkouts": https://git-scm.com/docs/git-read-tree - see this QA: https://stackoverflow.com/questions/4114887/is-it-possible-t...

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?

Re: Advantages of monolithic version control

#65

Post by fishywang »

humanrebar wrote: post #7
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…

> Namely, it's very easy to depend on other code that the organization has created. On the other hand, I've seen the other sides of this in monorepos: 1. It's too easy to depend on code, so there is dependency bloat when something simpler would work just as well. 2. It's relatively hard to depend on things not in the repo, reinforcing not-invented-here culture.

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

Re: Advantages of monolithic version control

#66

Post by stormbrew »

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.

Re: Advantages of monolithic version control

#68

Post by jncornett »

I think it boils down to two things that are not mutually exclusive: 1. Are you building a monolith? 2. What does your org chart look like?

I work for a fairly large company where a monorepo doesn’t make a whole lot of sense because each team runs several services that get released or patched independently. If you have a large product composed of many components that need to function together as a cohesive whole, go ahead, use a monorepo.

Re: Advantages of monolithic version control

#69

Post by petters »

fishywang wrote: post #63
zdw wrote: post #31

The argument against this is that other external-to-Google-but-started-by-Google projects like Golang and Android use the multirepo model, with gerrit. There are pros and cons to each - do you want to have a hugely churning "I always have to rebase/merge" repo under you, or multiple repos and trouble keeping them in sync? Having done both, I'm not sure which is better - it's probably very project specific.

Android uses multirepo model not because they want to, it's because they have to. You can't have a single repo Android's size in git and still run it snappy. All the tools, including the old repo tool and the new toolings around gerrit, are to make the actual multirepo model works like a single repo.

Yes, and lack of proper tools is of course the main reason against a monorepo. Google had to develop most of its dev tools internally.

Re: Advantages of monolithic version control

#70

Post by asdfgadsfgasfdg »

taneq wrote: post #38
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…

I can't wait for someone to implement a C interpreter in Haskell or something and boldly proclaim that imperative programming (called by another name, of course) is the way of the future.

Like Golang?
Post reply on HN