From: Joey Hess Date: Mon, 7 Jun 2021 17:28:36 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~91^2~282 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=570e93abfd44680fb9eb25e4c6ad52f69ed6299c;p=git-annex.git comment --- diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment new file mode 100644 index 0000000000..2f68e41293 --- /dev/null +++ b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_19_b34a9cf4114ed943fe4ba2de78eb0bbc._comment @@ -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. +""]]