single branch, version control system for individuals.
Who is this for?
Probably very few people. That said, it has been fun to develop and I, sloum, plan to use it for developing slope modules. Especially now that it supports branches (and merging those branches).
solo also now supports generating a web page and pushing it, along with a tarball of the repo to a remote (this functionality requires
soloweb to be installed on the system). There is no
pull equivalent, as this is largely meant to be a single system vcs with remote backup (ie. the remote is not intended as a marge source, but can be cloned - which solo refers to as
branch: create a new named working branch and switch the cwd to it, delete a branch, or switch to an existing working branch
combine: merges the head of a given branch into the current workspace.
combinedoes not automatically create a snap
create: make the current directory a solo repository
diff: view the line level changes between the current working directory and
download: copy a remote repository to the current directory, renaming it if desired
help: get detailed information on the various solo commands
history: view the history starting at
pick: move a file from a given branch/commit into the current working directory, clobbering any existing version
push: generate a website and tarball from the repo and push it to a server
revert: discard any changes between the current (unsnapped) directory and
snap: take a snapshot of the current repository state, this becomes the new
status: view the current branch name and a list of files that have changed, been added, or been deleted since
tag: apply a name to a given branch/snap combination
value: update metadata value's such as
version: display the solo version
For usage details run:
or with a specific command, for example:
solo help create
.soloignorecan be placed in the repo root if you like. Each line in the file can be a relative path to a file, folder, or group of files (via globbing
**). Any file listed in
.soloignorewill not be committed and will not show up for purposes of status or diff.
.soloignorehas not been added back in since the redesign. It is planned in the future. Note that solo will automatically ignore a
.gitdirectory for all purposes except
push, for which the
.gitfolder will still be included in the resulting tarball. Initializing a repository will place a
.solofolder in the root folder of the repository. This folder contains all of the solo data. If you ever want to stop using solo for a project or start from scratch with the given repo simply recursive delete the folder (
rm -rf .solo). In general it is likely best to not mess around in the
.solofolder, as the program will handle all of the edits and may become "confused" if things are not kept how it likes them ;)
solouses the, more or less standard, unix tools
tar. If you plan to use the
pushfeature of solo you will also need the program
solowebinstalled. It is available from the soloweb repository and can be acquired by running
solo download https://slope.colorfield.space/solo/repos/soloweb.
solo, as a program built in an interpreted language, also requires the slope language interpreter to be installed. It needs to be version
1.2.0or higher as it uses some newer features (at time of writing). Other than that there are no additional slope modules needed. If you are needing to build the slope interpreter you will need a Go compiler >= version 1.16
solo_completions.bash is included in the repository. The Makefile will install it when invoked with sudo, doas, or root user. You can
source it manually or move it manually to
/usr/local/etc/bash_completion.d/ if you prefer... if you are using bash at all. This will provide some basic level of command completion, such that if you type
solo sn it should fill in
solo snap for you, while also retaining file and directory completions. This is by no means a necessary feature, but it is available for those that want it.
At present tags can be created, but cannot be loaded into the current workspace. Similarly, reverting to a prior snap or loading a prior snap into the current workspace cannot be done. Both of these will soon be added in some form or other. Most likely very conservatively (with as few options as possible and keep things reasonably simple).