move InodeSentinal from direct mode code to its own module

Will be used outside of direct mode for v6 unlocked files, and is already
used outside of direct mode when adding files to annex.
This commit is contained in:
Joey Hess 2015-12-09 15:42:16 -04:00
parent 8a818088a3
commit 3311c48631
Failed to extract signature
9 changed files with 93 additions and 61 deletions

View file

@ -325,12 +325,12 @@ 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 objects is unlocked
* 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 case where the associated files database is not used can be
* 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
need to open the database or do reconciliation, but can simply return none.