i think it would be useful to have a fourth kind of special remotes that connects to a dumb storage using sftp or rsync. this can be emulated by using sshfs, but that means lots of round-trips through the system and is limited to platforms where sshfs is available.
typical use cases are backups to storate shared between a group of people where each user only has limited access (sftp or rsync), when using bup is not an option.
an alternative to implementing yet another special remote would be to have some kind of plugin system by which external programs can provide an interface to key-value stores (i'd implement the sftp backend myself, but haven't learned haskell yet).
Ask and ye shall receive.
Sometimes I almost think that a generic configurable special remote that just uses configured shell commands would be useful.. But there's really no comparison with sitting down and writing code tuned to work with a given transport like rsync, when it comes to reliability and taking advantage of its abilities (like resuming). --Joey
big thanks, and bonus points for identical formats, so converting from directory to rsync is just a matter of changing
type
fromdirectory
torsync
in.git-annex/remote.log
and replacing the directory info withannex-rsyncurl = <host>:<dir>
in.git/config
. --chrysn
+1 for a generic user configurable backend that a user can put shell commands in, which has a disclaimer such that if a user hangs themselves with misconfiguration then its their own fault :P
I would love to be able to quickly plugin an irods/sector set of put/get/delete/stat(get info) commands into git-annex to access my private clouds which aren't s3 compatible.