From 8b8ee68a9c415d37ea8667c14a4afb16fdfcd8cb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 23 Nov 2020 13:00:20 -0400 Subject: [PATCH] update --- .../speed_up_annex.adjustedbranchrefresh.mdwn | 31 +++++++------------ 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn index 4898011540..7f53438816 100644 --- a/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn +++ b/doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn @@ -1,26 +1,19 @@ The --hide-missing and --unlock-present adjusted branches depend on whether the content of a file is present. So after a get or drop, -the branch needs to be updated to reflect the change. Currently this has to -be done manually, except git-annex sync does do it at the end. Can the -update be automated? +the branch needs to be updated to reflect the change. -Of course, it could be updated on shutdown whenever content was transferred -or dropped. The question really is, can it be done efficiently enough that -it makes sense to do that? And for that matter, can it be done efficiently -enough to do it more frequently? After every file or after some number of -files, or after processing all files in a (sub-)tree? +To avoid the user needing to do it manually, the +annex.adjustedbranchrefresh config automates it now. That is not yet +enabled by default, because it can be slow. -> Since the answer to that will change over time, let's make a config for -> it. annex.adjustedbranchrefresh -> -> The config can start out as a range from 0 up that indicates how -> infrequently to update the branch for this. With 0 being never refresh, -> 1 being refresh the minimum (once at shutdown), 2 being refresh after -> 1 file, 100 after every 99 files, etc. -> If refreshing gets twice as fast, divide the numbers by two, etc. -> If it becomes sufficiently fast that the overhead doesn't matter, -> it can change to a simple boolean. Since 0 is false and > 0 is true, -> in git config, the old values will still work. (done) +Can it be done efficiently enough to become default? +And how frequently can it update without being too slow? +After every file or after some number of files, or after processing +all files in a (sub-)tree, or only once at the end of a command? + +The config was designed as a numeric scale with the hope that it might +later become a simple boolean if it got fast enough. Since 0 is false +and > 0 is true, in git config, the old values will still work. Investigation of the obvious things that make it slow follows: