Mono or Multi, who cares

All configuration management that I do is using git. git is both fast and efficient. Different projects that I work on use either a mono-repo approach or a multi-repo approach. There are pros and cons with both. And lots of articles discussing the merits of each.

Lately I’ve found myself leaning more towards multi, but missing the positives associated with a single source repository.

I came across a tool that allows me through directory hierarchies to get the benefits of both.

meta is a tool for managing multi-project systems and libraries. It answers the conundrum of choosing between a mono repo or many repos by saying “both”, with a meta repo!

Why meta?

• clone a many-project architecture in one line
• give every engineer on your team the same project setup, regardless of where it’s cloned
• execute arbitrary commands against many repos to manage your projects
• meta repo keeps code in per project repos, benefiting deployment and reuse
• use the same tools you always use. no strange side effects of git submodules or subtree

You can see the instructions here for how to use meta.

In my work now I have a git repo in my project called meta. In it I reference the other repos that are part of my project. My directory structure when I clone my meta project using meta (checkouts all the repos reference in the projects .meta config) looks like below.

.
└── meta
    ├── repo1
    ├── repo2
    ├── ...
    └── repoN

I can now work in the assumption that there is a consistent directory layout and therefore leverage this appropriately, for e.g. soft linking content between repos, apply standards consistently etc.

Another tool that is useful in this context is asdf. Using asdf’s .tool-versions file at the meta directory, means I can ensure consistent tools/programming language sdk versioning when working in any of my projects repo’s.