err on the side of larger repository size

When a live update is removing a key, it might fail. So only count those
once they have succeeded. When a live update is adding a key, count it
immediately to avoid over-filling a repo.

This also makes the 1 minute delay between stale live changes checks
more defensible, because a stale live change can only cause us to err
more on the side of caution.

Annex/RepoSize.hs

@@ -57,7 +57,7 @@ getLiveRepoSizes quiet = do
 	go sizemap = do
 		h <- Db.getRepoSizeHandle
 		checkStaleSizeChanges h
-		liveoffsets <- liftIO $ Db.liveRepoOffsets h
+		liveoffsets <- liftIO $ Db.liveRepoOffsets h wantlivesizechange
 		let calc u (RepoSize size, SizeOffset startoffset) =
 			case M.lookup u liveoffsets of
 				Nothing -> RepoSize size
@@ -65,6 +65,13 @@ getLiveRepoSizes quiet = do
 					size + (offset - startoffset)
 		return $ M.mapWithKey calc sizemap
 
+	-- When a live update is in progress, only count it
+	-- when it makes a repository larger. Better to err on the side
+	-- of repositories being too large than assume that drops will
+	-- always succeed.
+	wantlivesizechange AddingKey = True
+	wantlivesizechange RemovingKey = False
+
 {- Fills an empty Annex.reposizes MVar with current information
  - from the git-annex branch, supplimented with journalled but
  - not yet committed information.