update
This commit is contained in:
parent
24fdd36e50
commit
8b8ee68a9c
1 changed files with 12 additions and 19 deletions
|
@ -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:
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue