diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2015-12-09 17:47:05 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2015-12-09 17:54:54 -0400 |
| commit | d2d501503d9aa19787466129394141c794bb84e6 (patch) | |
| tree | 3a0e3982e420ec42e2d90672628c4d63c7f78eff /doc/todo/smudge.mdwn | |
| parent | 76ccac53916d308aa4806d38bb8cfb6a9d1f9081 (diff) | |
use InodeCache when dropping a key to see if a pointer file can be safely reset
The Keys database can hold multiple inode caches for a given key. One for
the annex object, and one for each pointer file, which may not be hard
linked to it.
Inode caches for a key are recorded when its content is added to the annex,
but only if it has known pointer files. This is to avoid the overhead of
maintaining the database when not needed.
When the smudge filter outputs a file's content, the inode cache is not
updated, because git's smudge interface doesn't let us write the file. So,
dropping will fall back to doing an expensive verification then. Ideally,
git's interface would be improved, and then the inode cache could be
updated then too.
Diffstat (limited to 'doc/todo/smudge.mdwn')
| -rw-r--r-- | doc/todo/smudge.mdwn | 13 |
1 files changed, 2 insertions, 11 deletions
diff --git a/doc/todo/smudge.mdwn b/doc/todo/smudge.mdwn index 60cc65f3f..cc8da67d0 100644 --- a/doc/todo/smudge.mdwn +++ b/doc/todo/smudge.mdwn @@ -328,6 +328,8 @@ files to be unlocked, while the indirect upgrades don't touch the files. * 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. +* Also, Annex.Content.prepSendAnnex should check the InodeCache for + changes. * 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 @@ -338,17 +340,6 @@ files to be unlocked, while the indirect upgrades don't touch the files. (when not in direct mode). However, beware over-optimisation breaking the assistant or perhaps other long-lived processes. -* Update pointer files when dropping the content of a key. - - Check the associated files database to find associated files for the key. - - Verify that worktree files are not modified from the annexed object. - How? InodeCache could be maintained, but the smudge filer interface - wouldn't let it be updated when smudging a file. May need to take - an expensive path: - 1. stat object file - 2. stat worktree file - 3. if same stat, ok else hash worktree file - 4. stat worktree file again after checking hash; make sure it's - unchanged from earlier stat * Convert `git annex unlock` to stage a pointer file, and hard link to the annexed object (or write pointer file if annexed object not present). - Also needs to thaw annex object file |