summaryrefslogtreecommitdiff
path: root/doc/backends.mdwn
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-08-28 16:28:38 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-08-28 16:28:38 -0400
commitbbba6c19bd03f2b4a4ce8a38a2423c794826b1c5 (patch)
tree56f50f9c23018f5c4479a0503e1e6c9dcd57c83e /doc/backends.mdwn
parent999d5df90b013a7cc8a390c940785118400faf8a (diff)
update documentation for new, neutered key-value backends
Backends are now only used to generate keys (and check them); they are not arbitrary key-value stores for data, because it turned out such a store is better modeled as a special remote. Updated docs to not imply backends do more than they do now. Sometimes I'm tempted to rename "backend" to "keytype" or something, which would really be more clear. But it would be an annoying transition for users, with annex.backends etc.
Diffstat (limited to 'doc/backends.mdwn')
-rw-r--r--doc/backends.mdwn22
1 files changed, 7 insertions, 15 deletions
diff --git a/doc/backends.mdwn b/doc/backends.mdwn
index 9e698032d..f2f1c5580 100644
--- a/doc/backends.mdwn
+++ b/doc/backends.mdwn
@@ -1,24 +1,16 @@
-git-annex uses a key-value abstraction layer to allow file contents to be
-stored in different ways. In theory, any key-value storage system could be
-used to store file contents.
-
When a file is annexed, a key is generated from its content and/or metadata.
The file checked into git symlinks to the key. This key can later be used
to retrieve the file's content (its value).
-Multiple pluggable backends are supported, and a single repository
-can use different backends for different files.
-
-These backends can transfer file contents between configured git remotes.
-It's also possible to use [[special_remotes]], such as Amazon S3 with
-these backends.
+Multiple pluggable key-value backends are supported, and a single repository
+can use different ones for different files.
-* `WORM` ("Write Once, Read Many") This backend assumes that any file with
- the same basename, size, and modification time has the same content. So with
- this backend, files can be moved around, but should never be added to
+* `WORM` ("Write Once, Read Many") This assumes that any file with
+ the same basename, size, and modification time has the same content. So
+ files can be moved around, but should never be added to
or changed. This is the default, and the least expensive backend.
-* `SHA1` -- This backend uses a key based on a sha1 checksum. This backend
- allows modifications of files to be tracked. Its need to generate checksums
+* `SHA1` -- This uses a key based on a sha1 checksum. This allows
+ modifications of files to be tracked. Its need to generate checksums
can make it slower for large files.
* `SHA512`, `SHA384`, `SHA256`, `SHA224` -- Like SHA1, but larger
checksums. Mostly useful for the very paranoid, or anyone who is