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 The --hide-missing and --unlock-present adjusted branches
depend on whether the content of a file is present. So after a get or drop, 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 the branch needs to be updated to reflect the change.
be done manually, except git-annex sync does do it at the end. Can the
update be automated?
Of course, it could be updated on shutdown whenever content was transferred To avoid the user needing to do it manually, the
or dropped. The question really is, can it be done efficiently enough that annex.adjustedbranchrefresh config automates it now. That is not yet
it makes sense to do that? And for that matter, can it be done efficiently enabled by default, because it can be slow.
enough to do it more frequently? After every file or after some number of
files, or after processing all files in a (sub-)tree?
> Since the answer to that will change over time, let's make a config for Can it be done efficiently enough to become default?
> it. annex.adjustedbranchrefresh And how frequently can it update without being too slow?
> After every file or after some number of files, or after processing
> The config can start out as a range from 0 up that indicates how all files in a (sub-)tree, or only once at the end of a command?
> infrequently to update the branch for this. With 0 being never refresh,
> 1 being refresh the minimum (once at shutdown), 2 being refresh after The config was designed as a numeric scale with the hope that it might
> 1 file, 100 after every 99 files, etc. later become a simple boolean if it got fast enough. Since 0 is false
> If refreshing gets twice as fast, divide the numbers by two, etc. and > 0 is true, in git config, the old values will still work.
> 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)
Investigation of the obvious things that make it slow follows: Investigation of the obvious things that make it slow follows: