We have preferred content, which is advisory, and numcopies, which is
enforced (except by git annex move). What is missing is an expression
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, ornot 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 tonot inallgroup=anchor. --Joey
To give a specific example of what I want to do:
I have a bunch of repos
A-C should get all data. A-F trust A-C to always retain all data, online checks for availability are not needed because A-C run frequent fsck. Ideally,
git annex dropshould be no-op in A-C.D-F should retain data as long as it's not been saved in all of A-C. As soon as A-C have copies,
git annex dropin D-F should drop that content; before that, they must not drop said content.Richard
copies=,lackingcopies=,approxlackingcopies=,inallgroup=.The last is where the complication comes in. Seems to need a cache of places the key was just now verified to be present, which can be used to avoid unnecessary redundant active verification (for example "not (copies=2 and inallgroup=bar)" would otherwise redundantly check some remotes). The numcopies checking code should use the same cache too.