2010-10-19 19:59:40 +00:00
|
|
|
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 more than one can be used
|
|
|
|
|
to store different files' contents in a given repository.
|
|
|
|
|
|
|
|
|
|
* `WORM` ("Write Once, Read Many") This backend stores the file's content
|
|
|
|
|
only in `.git/annex/`, and 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 or changed.
|
|
|
|
|
This is the default, and the least expensive backend.
|
|
|
|
|
* `SHA1` -- This backend stores the file's content in
|
|
|
|
|
`.git/annex/`, with a name based on its sha1 checksum. This backend allows
|
|
|
|
|
modifications of files to be tracked. Its need to generate checksums
|
2010-10-27 19:02:05 +00:00
|
|
|
can make it slower for large files. **Warning** this backend is not ready
|
|
|
|
|
for use.
|
2010-10-19 19:59:40 +00:00
|
|
|
* `URL` -- This backend downloads the file's content from an external URL.
|
