mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source
This commit is contained in:
Joey Hess 2020-11-23 13:00:20 -04:00
parent 24fdd36e50
commit 8b8ee68a9c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 12 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

31
doc/todo/speed_up_annex.adjustedbranchrefresh.mdwn
View file

@ -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: