solo

A simple, 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 scp, tar, and 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 download).

Commands

• 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. combine does 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 HEAD
• 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 HEAD
• 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 HEAD
• snap: take a snapshot of the current repository state, this becomes the new HEAD
• status: view the current branch name and a list of files that have changed, been added, or been deleted since HEAD
• tag: apply a name to a given branch/snap combination
• value: update metadata value's such as pushpath, description, and image
• version: display the solo version

For usage details run:

solo help

or with a specific command, for example:

solo help create

Files

The file .soloignore can 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 * or **). Any file listed in .soloignore will not be committed and will not show up for purposes of status or diff. .soloignore has not been added back in since the redesign. It is planned in the future. Note that solo will automatically ignore a .git directory for all purposes except push, for which the .git folder will still be included in the resulting tarball.

Initializing a repository will place a .solo folder 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 .solo folder, as the program will handle all of the edits and may become "confused" if things are not kept how it likes them ;)

Dependencies

solo uses the, more or less standard, unix tools diff, diff3, and tar. If you plan to use the push feature of solo you will also need the program soloweb installed. 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.0 or 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

Other

A file 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<tab> 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.

Future

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).