check InodeCache in inAnnex et al
This avoids querying the database when the content file doen't exist (or otherwise fails the provided check). However, it does add overhead of querying the database, and will certianly impact performance.
This commit is contained in:
parent
2b8f6b8b2f
commit
f80a3d8cd0
2 changed files with 18 additions and 10 deletions
|
@ -84,7 +84,10 @@ inAnnex key = inAnnexCheck key $ liftIO . doesFileExist
|
|||
inAnnexCheck :: Key -> (FilePath -> Annex Bool) -> Annex Bool
|
||||
inAnnexCheck key check = inAnnex' id False check key
|
||||
|
||||
{- Generic inAnnex, handling both indirect and direct mode.
|
||||
{- inAnnex that performs an arbitrary check of the key's content.
|
||||
-
|
||||
- When the content is unlocked, it must also be unmodified, or the bad
|
||||
- value will be returned.
|
||||
-
|
||||
- In direct mode, at least one of the associated files must pass the
|
||||
- check. Additionally, the file must be unmodified.
|
||||
|
@ -93,9 +96,17 @@ inAnnex' :: (a -> Bool) -> a -> (FilePath -> Annex a) -> Key -> Annex a
|
|||
inAnnex' isgood bad check key = withObjectLoc key checkindirect checkdirect
|
||||
where
|
||||
checkindirect loc = do
|
||||
whenM (fromRepo Git.repoIsUrl) $
|
||||
error "inAnnex cannot check remote repo"
|
||||
check loc
|
||||
r <- check loc
|
||||
if isgood r
|
||||
then do
|
||||
cache <- Database.Keys.getInodeCaches key
|
||||
if null cache
|
||||
then return r
|
||||
else ifM (sameInodeCache loc cache)
|
||||
( return r
|
||||
, return bad
|
||||
)
|
||||
else return bad
|
||||
checkdirect [] = return bad
|
||||
checkdirect (loc:locs) = do
|
||||
r <- check loc
|
||||
|
|
|
@ -325,14 +325,11 @@ files to be unlocked, while the indirect upgrades don't touch the files.
|
|||
|
||||
#### implementation todo list
|
||||
|
||||
* inAnnex check should fail in the case where an annexed object is unlocked
|
||||
and has had its content changed. Could use an InodeCache for
|
||||
such objects. This parallels how inAnnex checks work for direct mode.
|
||||
* Reconcile staged changes into the associated files database, whenever
|
||||
the database is queried.
|
||||
* See if the cases where the associated files database is not used can be
|
||||
optimised. Eg, if the associated files database doesn't exist at all,
|
||||
we know smudge/clean are not used, so queries for associated files don't
|
||||
* See if the cases where the Keys database is not used can be
|
||||
optimised. Eg, if the Keys database doesn't exist at all,
|
||||
we know smudge/clean are not used, so queries don't
|
||||
need to open the database or do reconciliation, but can simply return none.
|
||||
Also, no need for Backend.lookupFile to catKeyFile in this case
|
||||
(when not in direct mode).
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue