4 ms·

Does a lot of the pain from a monorepo come from trying to use a tool - Git - that is explicitly designed to support distributed repositories? Wouldn't things b

by chvid 8y ago

Does a lot of the pain from a monorepo come from trying to use a tool - Git - that is explicitly designed to support distributed repositories? Wouldn't things be easier if you used eg. Subversion instead? That is a tool that was designed around a client/server paradigm and had a single repository as its main use case.

icebraining 8y ago
Git was designed for a monorepo (the kernel). When people talk about monorepo, they mean a single history line.
- chvid 8y ago
  It is just the feeling I get when I see how it is used. That it is being misused. If you have a corporate setting with a single Jira/Stash/Bamboo installation keeping all the company's stuff in a single central place. Then this design where git copies (clones) the full repository on the local machine just seems like a misfit and source of lots of pain (ie. just being slow and at times unstable, local repository not pushed back to origin, multiple history lines etc.). It seems to me that things would have been better served with a more primitive client/server orientated tool like Subversion.
- rkangel 8y ago
  The kernel is not a monorepo. The kernel is a large(ish) repo. A monorepo would be if you put the kernel AND userspace in the same repo (e.g. all the code for a Yocto distro). To me, when people talk about a monorepo they are talking about putting separate pieces of the architecture in a single repo. It's a great example actually. If it was all in a monorepo and you could release it together then you wouldn't have to worry about the breaking userspace, you could make the changes to both sides at once. In practice because that's not how releasing works in that environment, you can't do that.
rkangel 8y ago
Anecdotally - I worked on a ~1 million lines of C project in SVN for a number of years (it was a Bluetooth stack). SVN handled it (mostly) fine.

by chvid 8y ago

icebraining 8y ago

Git was designed for a monorepo (the kernel). When people talk about monorepo, they mean a single history line.

chvid 8y ago
It is just the feeling I get when I see how it is used. That it is being misused. If you have a corporate setting with a single Jira/Stash/Bamboo installation keeping all the company's stuff in a single central place. Then this design where git copies (clones) the full repository on the local machine just seems like a misfit and source of lots of pain (ie. just being slow and at times unstable, local repository not pushed back to origin, multiple history lines etc.). It seems to me that things would have been better served with a more primitive client/server orientated tool like Subversion.
rkangel 8y ago
The kernel is not a monorepo. The kernel is a large(ish) repo. A monorepo would be if you put the kernel AND userspace in the same repo (e.g. all the code for a Yocto distro). To me, when people talk about a monorepo they are talking about putting separate pieces of the architecture in a single repo. It's a great example actually. If it was all in a monorepo and you could release it together then you wouldn't have to worry about the breaking userspace, you could make the changes to both sides at once. In practice because that's not how releasing works in that environment, you can't do that.

rkangel 8y ago

Anecdotally - I worked on a ~1 million lines of C project in SVN for a number of years (it was a Bluetooth stack). SVN handled it (mostly) fine.