Rinko Hub
Sign in Sign up
Documentation menu

Your first repository

From your Development Root, create a project with nexa init or bring one in with nexa get, naming it with -p instead of changing into it — and stop before recording, so its private files can be protected first.

This page creates a project in your Development Root. You do it from the root — you never change into the project directory. Each command names the project it acts on, so one terminal at the root drives every project beneath it.

It deliberately stops before the first record. The next page protects the project's private files and records it; the page after that hosts it on Rinko Hub. That order is the point: protection applies from the version it is recorded in, and publishing uploads every version recorded so far.

Prerequisites

  • A Development Root — the page before this one. The examples use ~/Development as the root and my-project as the project; substitute your own.
  • An authorized machine, which publishing will need.
Where this page sits in the path 
nexa login
cd ~/Development
nexa root

nexa init my-project                  # this page
# protect private files, then record  # the next page
# nexa publish -p my-project          # the page after
-p names the project

-p my-project (long form --project my-project) tells a command which project in the root to act on, by its directory name. It is how you address one project while standing among many. Forget it and the command does nothing, and lists the projects it could have meant:

nexa record at the root, without -p 
a project must be named in ~/Development
Projects:
  my-project
error: cannot do that here: name a project with `-p <project>`, for example `nexa status -p <project>`

Create the project

From the root, name the project to create:

Command 
nexa init my-project
Expected output
Initialised Nexa repository `my-project` in Development Root ~/Development
Created workspace `main`

What happens

nexa init my-project makes ~/Development/my-project a managed project — creating the directory if it does not exist yet, or adopting it as it is if it does, with your files left exactly as they were. The root records it as a working context, and a workspace called main is created to record into. Nothing is recorded yet.

nexa init -p my-project does exactly the same, and works from anywhere inside the root — including for a nested folder, such as nexa init -p group/api.

Two things it does not do. It does not create a .nexa/ directory inside the project — the root's own .nexa/ holds the control state for every project beneath it, and the project directory stays plain files. And it does not touch the project's siblings: ~/Development/other-project stays unmanaged until you nexa init other-project too.

To see every project the root manages:

Command 
nexa contexts
Expected output
LOCAL	REPOSITORY	BRANCH	WORKSPACE
my-project	local:my-project	main	main
The Development Root is not one big repository

~/Development/.nexa is control state for many independent projects, not a repository spanning all of them. Each project you init is its own repository with its own history, and is published on its own. Making the root itself a repository would put every project into one history, which is the opposite of what the root is for.

Prefer to work inside the project directory?

You can also cd into a project and run the same commands without -p, the way you would with Git — the directory you are standing in names the project. It is the same repository either way, and you can switch between the two styles at any time. Working inside a project directory covers it.

Starting from an existing repository

If the repository already exists on Rinko Hub — someone else published it, or you did from another machine — you do not init it. From the Development Root, nexa get owner/repository brings it in as a project. Working the Nexa way covers this.

Its labels come with it — a label belongs to the repository — and so does the policy each of its versions was recorded under. Until your root's .nexapolicy has a project block for it, the policy pinned to its selected version keeps governing what you record. Read the next page before adding files of your own: a label the repository does not have cannot protect anything in it.

Do not record yet

The project exists and nothing is recorded. Leave it that way until its private files are protected. A version records the whole working tree, and a file recorded before it was labelled stays readable in that version for good — labelling it later protects only the versions after.

Already recorded?

If you have recorded a version that holds a credential, that version keeps it readable, and publishing uploads it. Treat the credential as exposed: rotate it, then protect the file as the next page describes so the replacement is sealed.

Next step

Protect private files before hosting — decide which files are private, label them, validate, and record the first version.