link to the locations of different tools when I know them. i marked
the ones I don't know about specially so we can document those as
well.
point to the Github releases for the standalone binaries upload
we stop supporting them, because there are better alternatives:
- use a distribution package (from your linux distribution), if available
- use a pyinstaller binary provided by us (they include all you need in 1 file and
thus have better compatibility properties and are easier to install than a wheel)
- install from source (pypi or git) if everything else fails
while SSH options can be specified through `~/.ssh/config`, some users
may want to use a completely different SSH command for their backups,
without overriding their $PATH variable. it may also be easier to do
ad-hoc configuration and tests that way.
plus, the POLA tells us that users expects something like this to be
supported by commands that talk to ssh. it is supported by rsync, git
and so on.
this is a crude hack for now, and could use a better table of contents
but at least we have some way of linking and showing the different
internal functions
the next phase here is obviously to document that API through the
addition of docstrings. a static api.rst could also be easier to read,
but maybe that could go through some docstrings as well, to be tested
right now, the update_usage script regenerates the usage files at
every call
by moving this into the makefile, we make those files be generated
only when the source file change, which makes testing docs much faster
- reduce redundancy (platforms are documented in README.rst)
- reformat to 80 chars width
- clarify checkpoints
- remove workarounds for stuff that was fixed
sets the default repository to use, e.g. like:
export BORG_REPO=/mnt/backup/repo
borg init
borg create ::archive
borg list
borg mount :: /mnt
fusermount -u /mnt
borg delete ::archive
outdated - it just showed different levels of zlib compression,
but not we additionally have "lzma", "lz4" and "none" compression.
the "usage" and "internals" docs give some hints about them, too.
found out why it could not install llfuse into virtual env: it always complained about
not being able to find fuse.pc - which is part of libfuse-dev / fuse-devel and was missing.
once one adds the fuse dev stuff, llfuse installs to virtual env without problems.
