update slightly

This commit is contained in:
Joey Hess 2018-11-13 15:13:44 -04:00
parent 4b14438c9a
commit e2589670da
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -4,20 +4,18 @@ will want to drop `archive/bar`, but `git annex get --auto` will want to get
`foo`. `git annex sync --content` will do both operations, getting and then
dropping the key. Running these commands repeatedly churns unncessarily.
In the preferred content expressions for standard groups, the only
place this bug can be triggered involves archive directories of
repositories in the client group. A file both in the archive directory and
in another directory has indeterminite status.
Fixing this needs a map from key to files using it. Then, when checking
preferred content of `archive/bar`, it can see that `foo` also uses the
key. Since `foo` is wanted, it should not drop the key, even though
`archive/bar` is not wanted.
Such a map exists, in the keys database, but only in v6 mode repositories.
So, this seems solvable in v6 repositories, but not in v5.
Such a map exists, in the keys database, but only in v7 mode repositories.
So, this seems solvable in v7 repositories, but not in v5.
Also, the associated files map may not be accurate at all times, so that's
a wrinkle to using it for this. --[[Joey]]
(See [[bugs/preferred_content_and_deduplication]] for a user bug report of
the same thing, with some suggestions for workarounds too.)
In the preferred content expressions for standard groups, the only
place this bug can be triggered involves archive directories of
repositories in the client group. A file both in the archive directory and
in another directory has indeterminite status.
a wrinkle to using it for this. Also, only unlocked files get into the
associated files map. --[[Joey]]