Hacker News Reader

Comment by viraptor | Hacker News Reader

Prevents. Instead of cloning just one of your repos and expecting it to work, I clone `indygreg2` and need to answer:

- is there one build system for everything, or one per project?

- are there dependencies between projects?

- are they symlink-vendored? (which means that potentially I need more than one toolchain if projects A and B are in different languages)

- are they completely separate? (do they always assume latest version of your projects, or do they have reasonable version qualifiers)

- are any elements included cross-project, or can I just copy one directory and package it separately?

Those and other similar questions just don't exist (in well maintained projects) that have separate repos. I know that I can clone one project and build it.

View on HN

Instead of cloning just one of your non-monolithic repositories and expecting it to "just work" I need to answer:

- How does the build system integrate multiple, discrete repositories into a unified system?

- What are the dependencies between the repositories?

- How are the sub-repositories laid out on disk? Do the separate repositories use separate toolchains?

- How do I decide when to update the reference to a sub-repository? Are they completely separate? Versioned as one logical entity?

- Do separate repositories reference elements in each other? Can I copy files between repositories or should certain files live in certain repositories?

These and other similar questions exist when you use multiple repositories.

(I hope you see that multiple, discrete repositories aren't a panacea and there is a counterpoint to each of your points.)

I don't agree with some of the counterpoints. Not because they couldn't exist in theory, but because we already worked out some common solutions for them and by cloning a separate repository, I expect that kind of problem to be one of: solved, documented in red big letters, or worthy of a bug report.

1. (build integration) All popular build systems have some dependency management answers. Even down to C's `autotools` and `pkg-config` which will at least tell you what you're missing. But more likely something like pip / gem / cargo which can just get it for you. Whether that's a released version, or another repo - none of my business.

2. (dependencies between repos) Same as 1. They're separate projects.

I don't think these apply at all:

3. (sub-repositories) I don't see a difference between sub-repos and symlinking to a repo outside. This is a problem of single repo.

4. (sub-repositories update) Same as 3 - it's the same as one repository - avoid sub-repos unless you want to pretend you have one big repo with everything.

5. (moving elements) I think that's a straw man. Does anyone have a reasonable expectation that a file containing code can be moved between repositories without issues?

While no repository layout is perfect and there are always pros and cons, I think those examples are really bad as counterpoints.

Reply on news.ycombinator.com