how many projects per repository? - Programming On Unix

Users browsing this thread: 1 Guest(s)

I wanted to ask a question: what do you think about "mono-repos", aka: one repo for a bunch of projects.
One of the alternatives, which seems to me the more common solution, is to have one repo per project (say, "project-repo").
And the other alternative, which is also quite common, is to have projects divided into sub-projects: repos which depends on other repos, this mostly happens within big projects (say, "split-repo"?).

Personally, I've worked with mono-repos at work. It ended that, because of some peoples lack of skill, mono-repo was split, with repos depending on other repos (split-repo, since our codes had to work together anyway, and even shared code I wrote as libraries). Well, it was not really a sub-project division, but rather a per-dev division, since the unskilled one kept all his projects into a single repo (but at least could not pollute other's repos...).

I have also contributed to "project-repos", and am still contributing to some "split-repos", which are kind of "encouraged" by git's submodule (shitty) system.

My personal preference clearly goes to mono-repo, because it makes things easy as a dev: I have code I share between my projects. I put it in a subdirectory, each project have own directory. They even usually have their own branches (since I use git), that, when they have a changeset ready, gets rebased (so that I can keep a sane history) and then merged into master.
This makes things pretty easy from both my side (which I consider most important one, since I'm the one working on it) and on user's side which have to bother about less dependencies.
But, this approach also have disadvantages:
* it makes it hard to point others at a specific project, since everything is in the same repo,
* if a project grows too much, it can become quite heavy, which can become a problem depending on connnection,
* history is "polluted", as in, it will not only be the history of the single part you're interested in. I try to workaround that by using prefix in commits' title, and with git it can be solved by specifying the directory you want history of, but that's still not easy/practical,
* it requires discipline, in order to keep things organized. In my case, I forbid myself to touch multiple project's source-code in a single commit. Note that I don't consider the build system as code, to the contrary, I think it makes a lot of sense to have build system considered a project in it's own.

The "project-repo" approach, which is probably the most common one, requires less discipline, but require more user's intervention, since it is then required to clone all required repositories.

Both of those approaches have a big issue, though. If the project have some sub-parts with heavy files, like a game, there are technical issues when you try to clone or update the repo: bandwidth requirements, even if you don't intend to work on graphical, audio, or gameplay parts (usually called assets, but a recent discussion made me think it's a bad idea to call those assets, because that implies that the engine is worth nothing. Programmers are worth nothing...).
This problems is solved by the "split-repo" approach, but this approach usually also introduces difficulties when someone tries to work with the whole project.

So, which approach do you use?
In all situations?

Messages In This Thread
how many projects per repository? - by freem - 22-02-2021, 10:12 PM
RE: how many projects per repository? - by venam - 23-02-2021, 05:49 AM
RE: how many projects per repository? - by jkl - 23-02-2021, 03:15 PM