Set up a Local Filesystem Repository¶

A FlexVault repository normally lives in S3-compatible object storage, as described in Set up a Remote Repository. It can also live on a local filesystem path, which is useful for solo projects or for trying FlexVault out without setting up a bucket.

When to use one¶

A local filesystem repository suits:

• Solo projects that live on a single machine.
• Evaluating FlexVault before committing to a storage provider.

Use object storage instead when the repository is shared between people or machines, or when you need the durability guarantees of a hosted service.

Create the repository¶

The target directory must already exist, and the path in the URI must be absolute.

On Linux and macOS the URI has three slashes, as in file:///path/to/my-repo: two belong to the URI scheme and the third is the root of the filesystem. On Windows, a drive letter takes the place of that third slash, as in file://c:/path/to/my-repo.

mkdir -p /path/to/my-repo
fxv repo new file:///path/to/my-repo --admin-username alice --admin-email alice@example.com

New-Item -ItemType Directory -Force -Path C:\path\to\my-repo | Out-Null
fxv repo new file://c:/path/to/my-repo --admin-username alice --admin-email alice@example.com

None of the --s3-* flags apply here. As with an object storage repository, --admin-username is required and seeds the repository's first user.

Create a workspace against it¶

Point fxv init at the same file:// URI:

fxv init file:///path/to/my-repo --path ./my-workspace

fxv init file://c:/path/to/my-repo --path ./my-workspace

From here the workflow is identical to the object storage setup: add a user, log in, snapshot, and publish. See Add your user and publish.

Back up the repository yourself¶

There is no remote copy of a local filesystem repository. The repository directory holds your published history, and if you lose it, that history is gone. Back that directory up the same way you back up anything else important on the machine.

Your workspace is not a backup. It holds your local draft revisions and a copy of the files you are working on, not the repository's full published history.

Local-only workspaces are another quick-and-dirty option¶

fxv init --local-only creates a workspace with no external repository at all, rather than a workspace connected to a separate filesystem repository. Everything, including published revisions, is stored inside the workspace's .fxv_workspace directory.

fxv init --local-only

This creates the workspace in the current directory. It is the least durable option: deleting .fxv_workspace destroys all history irrevocably. --local-only does not take a path, and cannot be combined with a repository URI. Prefer a file:// repository over --local-only, since it at least separates your repository from your working files.

When you outgrow it¶

Once the project involves other people or another machine, create a repository backed by object storage and work against that instead. Set up a Remote Repository covers choosing a provider and creating the repository.