Added required content configuration.

This includes checking when dropping files that any required content
configuration is satisfied. However, it does not yet include an active
check on the required content; the location log is trusted when checking
the required content expression.
This commit is contained in:
Joey Hess 2014-03-29 15:20:55 -04:00
parent f2ddf9a299
commit 065248f3d2
10 changed files with 140 additions and 37 deletions

17
doc/required_content.mdwn Normal file
View file

@ -0,0 +1,17 @@
Required content settings can be configured to do more complicated
things than just setting the required number of [[copies]] of your data.
For example, you could require that data be archived in at least two
archival repositories, and also require that one copy be stored offsite.
The format of required content expressions is the same as
[[preferred_content]] expressions.
Required content settings can be edited using `git annex vicfg`.
Each repository can have its own settings, and other repositories will
try to honor those settings when interacting with it.
While [[preferred_content]] expresses a preference, it can be overridden
by simply using `git annex drop`. On the other hand, required content
settings are enforced; `git annex drop` will refuse to drop a file if
doing so would violate its required content settings.
(Although even this can be overridden using `--force`).

View file

@ -5,3 +5,19 @@ like preferred content, which is enforced. So, required content.
For example, I might want a repository that is required to contain
`*.jpeg`. This would make get --auto get it (it's implicitly part of the
preferred content), and would make drop refuse to drop it.
> I've implemented the basic required content. Currently only configurable
> via `vicfg`, because I don't think a lot of people are going to want to
> use it.
>
> Note that I did not yet add the active verification discussed below.
> So if required content is set to `not inallgroup=backup`, or
> `not copies=10`, trying to drop a file will not go off and prove
> that there are 10 copies or that the file is in every repository in
> the backup group. It will assume that the location log is accurate
> and go by that.
>
> I think this is enough to cover Richard's case, at least.
> In his example, A B and C are in group anchor and have required
> content set to `include=*`, and D E F have it set to
> `not inallgroup=anchor`. --[[Joey]]