Troubleshooting

svn was not found on your PATH

revision: the 'svn' command was not found on your PATH; please install Subversion

revision drives the real svn binary and refuses to start without it. Confirm:

svn --version

If that fails, install Subversion — brew install subversion on macOS, apt install subversion, dnf install subversion or the equivalent on Linux.

If svn --version works in your shell but revision still cannot find it, revision is running with a different PATH. That usually means it was launched from a GUI or an editor rather than a login shell — an integrated terminal inherits the shell’s PATH, but a desktop launcher may not.

The install script says my platform is unsupported

install.sh: unsupported OS: freebsd
install.sh: unsupported architecture: armv7l

Prebuilt binaries exist for macOS on Apple silicon and Intel, and for Linux on x86-64 and 64-bit ARM. Everywhere else, build from source:

go install github.com/bapatchirag/revision/cmd/revision@latest

That covers anything else Go targets. Note that builds produced this way never self-update — re-run go install to upgrade.

Windows is not supported at all.

The install script cannot download the binary

install.sh: download failed: https://github.com/bapatchirag/revision/releases/download/v1.3.0/revision-linux-arm64
    This release may not include revision-linux-arm64. Build from source instead:
    go install github.com/bapatchirag/revision/cmd/revision@latest

The platform is supported, but the release the script asked for carries no asset for it. The usual cause is REVISION_VERSION pinned to an older tag: releases through v1.3.0 published only revision-darwin-arm64 and revision-linux-amd64. Drop the pin to take the latest release, or build from source as the message suggests.

The same message appears when the download itself fails — a proxy, a rate limit, no network. Retry once before concluding the asset is missing.

revision: command not found after install

The install script printed where it put the binary:

Installed revision to /Users/you/.local/bin/revision
Note: /Users/you/.local/bin is not on your PATH; add it to run 'revision'.

Add that directory to your PATH in your shell profile and reopen the shell:

export PATH="$HOME/.local/bin:$PATH"

Or reinstall to a directory that is already on your PATH:

REVISION_INSTALL_DIR=/usr/local/bin sh -c "$(curl -fsSL https://raw.githubusercontent.com/bapatchirag/revision/main/install.sh)"

If command -v revision finds a different copy than you expected, you have two installs — see which method should I use.

SSH key not added after 3 attempts

SSH key not added after 3 attempts; it is required for this working copy

revision prompted for the passphrase of the key at sshKeyPath three times and ssh-add rejected it each time. The working copy is served over svn+ssh://, so SVN cannot reach the repository without that key.

Work through it outside revision:

# 1. Is the agent running?
ssh-add -l

# 2. Does this key load at all?
ssh-add ~/.ssh/id_rsa

# 3. Is it even the right key for this host?
ssh -T <host>

Common causes:

• The wrong key. sshKeyPath defaults to ~/.ssh/id_rsa, but your repository may use id_ed25519 or a per-host key. Press S and set the SSH key field.
• No agent. If ssh-add -l reports Could not open a connection to your authentication agent, start one: eval "$(ssh-agent -s)".
• A ~/.ssh/config that selects a different key per host. revision only checks the one key it is configured with. Load the right key yourself with ssh-add before starting — revision uses whatever the agent already holds.

See Authentication for the full flow.

Authentication required — cache SVN credentials

authentication required — cache SVN credentials, then retry

revision runs svn with --non-interactive so it can never hang on a hidden prompt. Prime SVN’s own credential cache once, from the same working copy:

cd /path/to/working-copy
svn info

Answer the prompts. Every later revision action reuses what SVN stored.

Conflicts during an update

Before running an update, revision warns you when a file in the working copy is already conflicted. svn leaves those files untouched and updates everything else, so the update still succeeds — but the conflicted files stay conflicted.

Press m on a conflicted file in the Files panel to decide it side by side; see Resolving conflicts and rejects. For a tree or property conflict, which is not markers in a file, use svn directly:

svn status | grep '^C'      # what is conflicted
svn resolve --accept working path/to/file

Then press R in revision to re-read status.

Conflicts introduced by an update are reported the same way: the file shows up with a C status code in the Changes tree.

The editor will not open over a remote connection

e with editor set to native needs something that can open the file. Over Remote-SSH, a dev container or WSL, revision runs on the server, so it relies on the code command VS Code injects into the remote shell.

That injection is missing in one specific case: you opened a local folder and then ssh’d to the server yourself from the integrated terminal. VS Code’s environment is not carried across, so there is no window for native to talk to. It falls back to $EDITOR, and on a headless server the desktop opener then fails.

Fix it by choosing a terminal editor for those sessions — press S and set Editor to vim, nvim or nano. They run on the server, in the terminal panel, and edit the remote file in place.

Check the injection yourself:

command -v code

If that finds nothing inside a Remote-SSH terminal, the environment was not inherited.

See Opening files in an editor.

Live refresh is expensive on my working copy

live refresh: too large to scan — watching current changes only

While liveRefresh is on, revision looks at the working copy every second and a half. Each look stats SVN’s metadata database and the files svn status already reports, which costs the same whether the tree holds ten files or half a million. A full walk of the tree — what catches a brand-new file in a directory SVN has not been asked about yet — runs on a slower cadence, paced by how long the last one took, and is dropped entirely when it cannot finish inside its budget. That is what the toast above reports: the cheap look continues, so changes to the files on screen are still picked up.

On a network filesystem (NFS, SMB, sshfs) even the cheap look crosses the network, and the walk can be slow enough to be noticeable. Turn the watcher off:

• L — off for this session only.
• S → Live refresh → off, or "liveRefresh": false in the config file — off by default.

R still refreshes on demand.

watch working copy failed: …

The directory being watched became unreadable — it was deleted, renamed, or an unmounted network share went away. revision reports it once, then retries every fifteen seconds instead of every tick. It recovers on its own when the directory comes back.

An svn command timed out

svn status --xml: timed out after 30s

Every svn call runs under a deadline, and revision kills the process once it expires. Reads — status, log and diff — get 30 seconds, the svn info at startup gets 15, and a commit, an update or an action over a whole directory gets 60. None of them is configurable.

Hitting one means svn was slow, not that revision stalled. A very large working copy, a repository reached over a slow link, and a network filesystem are the usual causes. Nothing is left half-applied by revision itself: the reads change nothing, and a write that was killed leaves the working copy wherever svn had got to. Press R to see where that is.

Two things help:

• Scope the session smaller. svn is always run from the source directory, so P — change source path — narrows status and diff to one subtree instead of the whole checkout.
• Act on fewer files at once. A directory-wide stage, revert or delete is a single svn invocation under a single deadline; the same files one at a time each get their own.

The Command Log records the timeout against the command that hit it, so you can re-run that command in a shell and time it yourself.

Where is my config file?

$XDG_CONFIG_HOME/revision/config.json

When XDG_CONFIG_HOME is unset, that is ~/.config/revision/config.json on both macOS and Linux.

Not the macOS convention

revision does not use ~/Library/Application Support on macOS. If you are looking there, you will not find it. One path across both platforms means the same dotfiles work everywhere.

echo "${XDG_CONFIG_HOME:-$HOME/.config}/revision/config.json"

The file is created with defaults on first run. If it is missing, revision recreates it; if it is unreadable, revision starts on built-in defaults and prints a line to stderr rather than refusing to run. Deleting it is a safe reset.

A setting reverted on its own

A startup toast like config: logLimit 0 is invalid; reset to 100 means the value on disk was not one this build accepts — a retired theme name, a non-positive logLimit, an unknown editor. The default is written back in its place.

Unknown keys are ignored rather than deleted, so a config file shared between versions does not lose anything.

Something else

Check the Command Log with 4: it lists the svn invocations revision ran on your behalf, newest first, each marked ✓ or ✗. A failing action names the exact command, which is usually enough to reproduce it on the command line.

If that does not explain it, please open an issue with the command from the log, the svn --version output, and what you expected to happen.