mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions
git-annex/doc/copies.mdwn

49 lines
2.3 KiB
Text
Raw Normal View History

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.
2011-08-28 16:28:38 -04:00
Annexed data is stored inside your git repository's `.git/annex` directory.
Some [[special_remotes]] can store annexed data elsewhere.
update
2010-10-19 15:59:40 -04:00
docs for requirednumcopies Not implemented yet.
2021-01-05 14:22:27 -04:00
It's important that data not get lost by an ill-considered `git-annex drop`
command. So, git-annex can be configured to try to keep a number of copies
of a file's content available across all repositories.
By default, it keeps 1 copy; this is configured by running `git-annex
numcopies N`, or can be overridden on a per-file-type basis by the
annex.numcopies setting in `.gitattributes` files. The --numcopies switch
allows temporarily using a different value.
mincopies This is conceptually very simple, just making a 1 that was hard coded be exposed as a config option. The hard part was plumbing all that, and dealing with complexities like reading it from git attributes at the same time that numcopies is read. Behavior change: When numcopies is set to 0, git-annex used to drop content without requiring any copies. Now to get that (highly unsafe) behavior, mincopies also needs to be set to 0. It seemed better to remove that edge case, than complicate mincopies by ignoring it when numcopies is 0. This commit was sponsored by Denis Dzyubenko on Patreon.
2021-01-06 14:11:08 -04:00
When dropping content, git-annex checks with remotes to make sure If enough
other repositories cannot be verified to have copies, it will refuse to
drop it, avoid data loss.
In unusual situations, involving special remotes that do not support
locking, and concurrent drops of the same content from multiple
repositories, git-annex may violate the numcopies setting. It still
guarantees at least 1 copy is preserved. This can be configured by
running `git-annex mincopies N` or can be overridden on a per-file-type
basis by the annex.mincopies setting in `.gitattributes` files.
The --mincopies switch allows temporarily using a different value.
Note that [trusted repositories|trust]] are assumed to
continue to contain content, so checking them is skipped. So dropping
content from trusted repositories does risk numcopies and mincopies
later being violated.
docs for requirednumcopies Not implemented yet.
2021-01-05 14:22:27 -04:00
To express more detailed requirements about which repositories contain which
update for required content
2014-03-29 14:39:10 -04:00
content, see [[required_content]].
docs for requirednumcopies Not implemented yet.
2021-01-05 14:22:27 -04:00
## example
For example, consider three repositories: Server, Laptop, and USB. Both
Server and USB have a copy of a file, and numcopies is 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 numcopies of 2, in order to drop the file content from Laptop, it
would need access to both USB and Server.
Reference in a new issue Copy permalink