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:
Joey Hess 2015-12-10 14:51:04 -04:00
parent 2b8f6b8b2f
commit f80a3d8cd0
Failed to extract signature
2 changed files with 18 additions and 10 deletions

View file

@ -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).