Is a monorepo good for us?

[yanganto]

Introduction

There are 4 workspaces under RGB-WG, rgb, rgb-core, rgb-std, rgb-schemata. The rely on each other and share some similar dependencies.

Problems

• Once we have a new feature across these reports, we need to use git and branch for the cargo dependency.
  • The refactoring will take more effort.
  • Developers will not easily know others working status, because there is a possible new commit under the dependency branch, increasing the communication cost.
  • If test cross-crates will not be easy and instantly

Solution

Create a new repo, and merge current repos as parts into a big workspace, namely, keep the current repo in different folders, such that the code is still loosely coupled.

Each part can be a submodule(or can not be if we don't like submodules), so we can easily use git submodule update --recursive to have a whole view of our repos and still possibly use check different branches to know our crate compatibility on our different crates.

./Cargo.toml

./rgb/rgb
./rgb/cli
./rgb/fs
./rgb/psbt

./schemata/

./core/bin
./core/core
./core/stl
./core/bin

./std/std
./std/stl
./std/invoice

Advantage and shortage

• We can have a high-level PR on the main repo, to describe what we do, and we do not need to worry about which PR will be the first in a big feature.
• Repo can directly depend on others by path
• Easy to find out if there are any similar dependencies with different versions in our crates.
• There will be a single-page CI summary to know if something is breaking after this change
• ACL for every single part(rgb, rgb-core, rgb-std or rgb-schemata) will be hard, and all the repoes here are public, so it is not an issue for us.
• If only one part has code change, all test cases for the mono repo will run

Reference

• https://circleci.com/blog/monorepo-dev-practices/
• https://www.perforce.com/blog/vcs/what-monorepo

Wish to have your insight on this. @dr-orlovsky

[dr-orlovsky]

We have different repos since they must have different review and merge policies, different teams with different access etc.

Consensus code is very distinct from system code and application code by its security considerations, and security considerations can be enforced only at the level of a repository.

[dr-orlovsky]

Also, I expect RGB core to ossify, and RGB std lib not to require a lot of changes - once we have v1 release. So there will be no need for synchronized changes to a bunch of repos right now, when the speed of development before the release is highest.