4.8 KiB
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 branchcombine
: merges the head of a given branch into the current workspace.combine
does not automatically create a snapcreate
: make the current directory a solo repositorydiff
: view the line level changes between the current working directory andHEAD
download
: copy a remote repository to the current directory, renaming it if desiredhelp
: get detailed information on the various solo commandshistory
: view the history starting atHEAD
pick
: move a file from a given branch/commit into the current working directory, clobbering any existing versionpush
: generate a website and tarball from the repo and push it to a serverrevert
: discard any changes between the current (unsnapped) directory andHEAD
snap
: take a snapshot of the current repository state, this becomes the newHEAD
status
: view the current branch name and a list of files that have changed, been added, or been deleted sinceHEAD
tag
: apply a name to a given branch/snap combinationvalue
: update metadata value's such aspushpath
,description
, andimage
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).