Metaverse

Metaverse multirepo management revolves around two main axes of functionality:

• Workflow related functionality
• State Management

Installation

Metaverse requires rugged which in turns relies on a bundled libgit2 which is a Ruby native extension.

OSX

You need Cmake and pkg-config. If you have brew you can install by running :

brew install cmake pkg-config

1 - Workflow

Utilities

Checkout

meta checkout REF_OR_SHA

Checks out every repo to REF_OR_SHA - similar to git checkout REF_OR_SHA

Develop

meta develop

Checks out every repo to develop - ( shortcut for meta checkout develop )

Update

meta update REMOTE_NAME

Fetches from REMOTE_NAME in every repo - similar to git remote update REMOTE_NAME If REMOTE_NAME is omitted, defaults to fetching from all the remotes

Pull

meta pull

Pulls the changes from the main remote in every repo - similar to git pull origin

Branches

meta branches

Displays the branch at which every repo is.

Exec

meta exec COMMAND

Runs the specified shell command in every repo's working directory. Also passes the ENV used to invoke it to the shell command.

Features

New

meta feature new FEATURE_NAME

Creates a feature branch named feature/FEATURE_NAME on every repo managed by metaverse.

Load

meta feature load FEATURE_NAME REMOTE_NAME

Checks out every repo to feature/FEATURE_NAME in a detached HEAD mode. If the remote is set, tries to load the feature from that specific remote. Else, defaults to local features.

Send

meta feature send FEATURE_NAME REMOTE_NAME

Pushes the feature branch of the repos that have changes to the specified remote. It also automatically delete the branches that have no changes compared to develop.

Releases and bugfixes

Releases and bugfixes follow the same structure than the features, except that they are executed respectively using meta release and meta bugtfix.

2 - State Management

Sanity checks

meta can be used to perform some sanity checks on the state of the system.

Dirtiness

meta check dirtiness

Checks if the system is dirty. The system is considered dirty if a repo contains unstaged or uncommitted changes ( think about updating your .gitignores :) ) In such a case, it displays the list of affected repos.

Status

meta status

Checks the status of the system by running a dirtiness check, displays the output and the current state of the system. The branch at which the system is is deduced by counting the occurrences of every branch and picking the most frequent one.

System state

meta provides a set of features aimed toward taking a snapshot of the system, and reloading it afterwards.

How does it work ?

Snapshots are stored in a separate ref namespace in order to avoid collision with branches. Snapshots' refs in particular follow this refspec : refs/meta/local/snapshot/SNAPSHOT_NAME Similarly, refs are also used in addition to branches, to load features, releases, and bugfixes.

New

meta snapshot new SNAPSHOT_NAME

Take a snapshot of the system. The system stays in the same branch where it was before.

Load

meta snapshot load SNAPSHOT_NAME

Loads a previous snapshot of the system in a git detached HEAD mode. A good practice would be to create a feature, a release or a bugfix branch after loading a snapshot, prior to any modification on it.

Send

meta snapshot send SNAPSHOT_NAME REMOTE_NAME

Pushes a snapshot to the specified remote.

Configuration

meta stores it's configuration in a file named .meta.yml in the root folder of your workspace.

This is an example of a .meta.yml file :

  remotes:
    own: YOUR_OWN_REMOTE
    main: YOUR_MAIN_REMOTE
  ignore:
    - A_REPO_TO_IGNORE
    - A_REPO_TO_IGNORE
    - ..