improve handling of unmerged git-annex branches in readonly repo
git-annex info was displaying a message that didn't make sense in
context.
In calcRepoSizes, it seems better to return the information from the
git-annex branch, rather than giving up. Especially since balanced
preferred content uses it, and we can't just give up evaluating a
preferred content expression if git-annex is to be usable in such a
readonly repo.
Commit 6d7ecd9e5d
nobly wanted git-annex
to behave the same with such unmerged branches as it does when it can
merge them. But for the purposes of preferred content, it seems to me
there's a sense that such an unmerged branch is the same as a remote we
have not pulled from. The balanced preferred content will either way
operate under outdated information, and so make not the best choices.
This commit is contained in:
parent
5c35b3d579
commit
467d80101a
7 changed files with 46 additions and 27 deletions
6
Limit.hs
6
Limit.hs
|
@ -600,10 +600,12 @@ limitFullyBalanced mu getgroupmap groupname = Right $ MatchFiles
|
|||
maxsizes <- getMaxSizes
|
||||
-- XXX do not calc this every time!
|
||||
sizemap <- calcRepoSizes
|
||||
let keysize = fromMaybe 0 (fromKey keySize key)
|
||||
let hasspace u = case (M.lookup u maxsizes, M.lookup u sizemap) of
|
||||
(Just (MaxSize maxsize), Just (RepoSize reposize)) ->
|
||||
reposize + fromMaybe 0 (fromKey keySize key)
|
||||
<= maxsize
|
||||
if maybe False (`S.member` notpresent) mu
|
||||
then reposize <= maxsize
|
||||
else reposize + keysize <= maxsize
|
||||
_ -> True
|
||||
let candidates = S.filter hasspace groupmembers
|
||||
return $ if S.null candidates
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue