What are the main differences betwen repo and jiri?

Question

Google has been promoting since some time repo in Android context and has been adopted for some other projects non Android related.

In Google's operating system Fuchsia Jiri is being introduced.

What is the backround of these two tools? If they don't solve the same problem, what are their targets?

Answer 1

My so-far experience is that jiri allows you to cascade dependencies, so this goes one step further than Repo (where you can include other manifests, but cascading them in a fetch->include manner may be more tricky).

Repo allows you to set one root manifest that covers pretty much all your projects + allows local include. Each project is a stand-alone git repository. A single repo manifest is a self-contained entity that describes - by itself - an entire project structure.

Jiri allows you to combine several manifests. Each 'sub-repository' can define its own structure of git repositories.

In your top-level manifest (checkout manifest, or .jiri_manifest) you specify which project manifests to include. Each of the project manifests can then specify its own dependencies. Here's some exaples from the fuchsia project; Take a look at the fuchsia manifest file: it pulls in manifest/topaz from topaz project, which, in turn, imports manifest/peridot at specific GIT SHA as its own dependency.

You can't create this type of cascade dependency with repo easily, but there's also a downside here: jiri gives you a lot of flexibility, but may turn to maintenance burden, especially if at some point any of your code ends up depending on the same subcomponent, but different SHAs (and you can end up in this situation for a multitude of reasons).

Regardless of how complex your projects are I would typically recommend going with repo. This has a well established and proven track of record on very large projects (Android, integrating over 1100 projects). Jiri looks great on paper, but may backfire if you don't resolve your dependency issues in timely manner.