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

comment

Browse source
This commit is contained in:
Joey Hess 2021-06-07 13:28:36 -04:00
parent 1c35cacf8e
commit 570e93abfd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 19 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

19
doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="joey"
subject="""comment 19"""
date="2021-06-07T17:07:26Z"
content="""
It can't know if there are unlocked files without doing this scan.
Except for when annex.supportunlocked=false, but then that config option
would have the side effect of making git-annex *slower* at some point after
init, with the situations where it does hard to enumerate and probably
growing. This would be a hard behavior to explain to the user.
And there are numerous other points than the ones you listed where
git-annex accesses the keys db and would trigger a deferred scan. Eg, anytime
it might need to update a pointer file. Eg, when `git annex get` is run.
Avoiding using the keys db when annex.supportunlocked=false in all such
cases in order to avoid the scan would be effectively the same complexity
as continuing to support v5 repos, which I've NAKed before.
""]]