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

avoid reposize database locking overhead when not needed

Browse source 
Only when the preferred content expression being matched uses balanced
preferred content is this overhead needed.

It might be possible to eliminate the locking entirely. Eg, check the
live changes before and after the action and re-run if they are not
stable. For now, this is good enough, it avoids existing preferred
content getting slow. If balanced preferred content turns out to be too
slow to check, that could be tried later.
This commit is contained in:
Joey Hess 2024-08-28 10:52:34 -04:00
parent 09955deebe
commit e006acef22
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 43 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/todo/git-annex_proxies.mdwn
View file

@ -37,14 +37,6 @@ Planned schedule of work:
* Test that live repo size data is correct and really works.
* Avoid using checkLiveUpdate except when checking a preferred content
expression that does use balanced preferred content. No reason to pay
its time penalty otherwise.
Alternatively, make it not use file locking. It could rely on a database
transaction, or it could check the live changes before and after and
re-run the Annex action if they are not stable.
* When loading the live update table, check if PIDs in it are still
running (and are still git-annex), and if not, remove stale entries
from it, which can accumulate when processes are interrupted.