a0758bdd10
Based on my earlier benchmark, I have a rough cost model for how expensive it is for git-annex smudge to be run on a file, vs how expensive it is for a gigabyte of a file's content to be read and piped through to filter-process. So, using that cost model, it can decide if using filter-process will be more or less expensive than running the smudge filter on the files to be restaged. It turned out to be *really* annoying to temporarily disable filter-process. I did find a way, but urk, this is horrible. Notice that, if it's interrupted with it disabled, it will remain disabled until the next time restagePointerFile runs. Which could be some time later. If the user runs `git add` or `git checkout` on a lot of small files before that, they will see slower than expected performance. (This commit also deletes where I wrote down the benchmark results earlier.) Sponsored-by: Noam Kremen on Patreon
19 lines
786 B
Markdown
19 lines
786 B
Markdown
This is a todo for collecting changes that could lead to a v9 repository
|
|
version.
|
|
|
|
Currently, there does not seem to be enough reason to warrant one, but that
|
|
could change and if it does, these things could be included.
|
|
|
|
* Change locking of annexed files to use a separate lock file
|
|
rather than posix locking the file itself.
|
|
|
|
This would let write bits be removed from the file when
|
|
core.sharedRepository is set. See <https://git-annex.branchable.com/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/>
|
|
|
|
Note that windows already uses a separate lock file.
|
|
|
|
* Possibly enable `git-annex filter-process` by default. If the tradeoffs
|
|
seem worth it.
|
|
|
|
It does not currently incrementally hash, so implementing that first
|
|
would improve the tradeoffs.
|