diff options
| author |  Joey Hess <joey@kitenet.net> | 2014-01-22 16:35:32 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2014-01-22 16:35:32 -0400 |
| commit | 180fbceee03badc450c84c28ef8219fa68d80bd6 (patch) | |
| tree | 1739e92f46067ae0be84af6789b3d3b9adb09ee1 /doc | |
| parent | 9a5de318d15f0234080a6f0bd802fe073cf57334 (diff) | |
add "unused" preferred content expression
With a really nice optimisation that keeps it from having any overhead
in normal operation!
This commit was sponsored by Ulises Vitulli.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/todo/Limit_file_revision_history.mdwn | 15 |
1 files changed, 7 insertions, 8 deletions
diff --git a/doc/todo/Limit_file_revision_history.mdwn b/doc/todo/Limit_file_revision_history.mdwn index 9cdfe5e9b..c00b555b1 100644 --- a/doc/todo/Limit_file_revision_history.mdwn +++ b/doc/todo/Limit_file_revision_history.mdwn @@ -39,17 +39,16 @@ Finally, how to specify a feature request for git-annex? > So, let's spec out a design. > > * Add preferred content terminal to configure whether a repository wants -> to hang on to unused content. -> Something like "unused=true" I suppose, because not having a parameter -> would complicate preferred content parsing, and I cannot think -> of a useful parameter. (It cannot be a timestamp, because there's -> no way repos can agree on about when a key became unused.) +> to hang on to unused content. Simply `unused`. +> (It cannot include a timestamp, because there's +> no way repos can agree on about when a key became unused.) **done** > * In order to quickly match that terminal, the Annex monad will need -> to keep a Set of unused Keys. This should only be loaded on demand. +> to keep a Set of unused Keys. This should only be loaded on demand. +> **done** > NB: There is some potential for a great many unused Keys to cause > memory usage to balloon. > * Client repositories will end their preferred content with -> `and unused=false`. Transfer repositories too, because typically +> `and (not unused)`. Transfer repositories too, because typically > only client repos connect to them, and so otherwise unused files > would build up there. Backup repos would want unused files. I > think that archive repos would too. @@ -90,7 +89,7 @@ Finally, how to specify a feature request for git-annex? > client directly edits it, or deletes it, it loses the old version, > but the other client will still be storing that old version. > -> ## Stability analysis for unused= in preferred content expressions +> ## Stability analysis for unused in preferred content expressions > > This is tricky, because two repos that are otherwise entirely > in sync may have differing opinons about whether a key is unused, |