This commit is contained in:
Joey Hess 2010-10-17 11:51:53 -04:00
parent b471822cfe
commit cb1a0a387f

View file

@ -61,35 +61,6 @@ Oh yeah, "$file" in the above can be any number of files, or directories,
same as you'd pass to "git add" or "git rm".
So "git annex add ." or "git annex get dir/" work fine.
## copies
git-annex can be configured to try to keep N copies of a file's content
available across all repositories. By default, N is 1; it is configured by
annex.numcopies.
`git annex drop` attempts to check with other git remotes, to check that N
copies of the file exist. If enough repositories cannot be verified to have
it, it will retain the file content to avoid data loss.
For example, consider three repositories: Server, Laptop, and USB. Both Server
and USB have a copy of a file, and N=1. If on Laptop, you `git annex get
$file`, this will transfer it from either Server or USB (depending on which
is available), and there are now 3 copies of the file.
Suppose you want to free up space on Laptop again, and you `git annex drop` the file
there. If USB is connected, or Server can be contacted, git-annex can check
that it still has a copy of the file, and the content is removed from
Laptop. But if USB is currently disconnected, and Server also cannot be
contacted, it can't verify that it is safe to drop the file, and will
refuse to do so.
With N=2, in order to drop the file content from Laptop, it would need access
to both USB and Server.
Note that different repositories can be configured with different values of
N. So just because Laptop has N=2, this does not prevent the number of
copies falling to 1, when USB and Server have N=1.
## key-value storage
git-annex uses a key-value abstraction layer to allow file contents to be
@ -116,6 +87,37 @@ to store different files' contents in a given repository.
can make it slow for large files.
* `URL` -- This backend downloads the file's content from an external URL.
## copies
The WORM and SHA1 key-value backends store data inside your git repository.
It's important that data not get lost by an ill-though `git annex drop`
command. So, then using those backends, git-annex can be configured to try
to keep N copies of a file's content available across all repositories. By
default, N is 1; it is configured by annex.numcopies.
`git annex drop` attempts to check with other git remotes, to check that N
copies of the file exist. If enough repositories cannot be verified to have
it, it will retain the file content to avoid data loss.
For example, consider three repositories: Server, Laptop, and USB. Both Server
and USB have a copy of a file, and N=1. If on Laptop, you `git annex get
$file`, this will transfer it from either Server or USB (depending on which
is available), and there are now 3 copies of the file.
Suppose you want to free up space on Laptop again, and you `git annex drop` the file
there. If USB is connected, or Server can be contacted, git-annex can check
that it still has a copy of the file, and the content is removed from
Laptop. But if USB is currently disconnected, and Server also cannot be
contacted, it can't verify that it is safe to drop the file, and will
refuse to do so.
With N=2, in order to drop the file content from Laptop, it would need access
to both USB and Server.
Note that different repositories can be configured with different values of
N. So just because Laptop has N=2, this does not prevent the number of
copies falling to 1, when USB and Server have N=1.
## location tracking
git-annex keeps track of in which repositories it last saw a file's content.
@ -149,7 +151,8 @@ finding them:
## configuration
* `annex.uuid` -- a unique UUID for this repository
* `annex.numcopies` -- number of copies of files to keep (default: 1)
* `annex.numcopies` -- number of copies of files to keep across all
repositories (default: 1)
* `annex.backends` -- space-separated list of names of
the key-value backends to use. The first listed is used to store
new files. (default: "WORM SHA1 URL")