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

update on status

Browse source
This commit is contained in:
Joey Hess 2022-01-19 15:53:14 -04:00
parent 9d5db6a09a
commit cd2158d98d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 41 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment
View file

@ -7,20 +7,21 @@ This is going to need two repository version bumps:
v9: Add the upgrade lock file, and all git-annex processes take a shared
lock to avoid the repository being upgraded out from under them.
Upgrade is skipped when assistant is running.
v10: Skipped until the upgrade lock file is of a certain age. Take upgrade
lock before increasing annex.version.
lock before upgrading.
In v10, stop locking content files and lock separate lock files.
This way, an old version of git-annex cannot be used in the v9 repository,
and so the v10 upgrade only needs to worry about any git-annex processes
that were started in v8.
The age could be eg 1 month, which assumes that no old git-annex process
like `git-annex move --to remote` is still running after that long.
The age could be eg 1 month, which assumes that no pre-v9 git-annex
process like `git-annex move --to remote` is still running after that long.
Of course, that is still an assumption, but it can be pushed out as long as
it takes to feel comfortable with it. Maybe 1 year?
it takes to feel comfortable with it. Maybe 1 year? The only disadvantage
really is that any v11 upgrade would also get deferred.
Since the assistant can possibly run for longer than a year without
restarting, the v10 upgrade would need to be skipped when the assistant is
running.
`git-annex upgrade --version=10` could be available to speed up that
upgrade. The user would be responsible for making sure there are no such

29
doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment Normal file
View file

@ -0,0 +1,29 @@
[[!comment format=mdwn
username="joey"
subject="""comment 12"""
date="2022-01-19T19:55:10Z"
content="""
What kind of locking is needed for the v10 upgrade? Everything else is in
place now, but the actual locking is TBD.
My plan above calls for a way to detect if another git-annex process
(v9 or above) is running in the repo. That will be hard to implement
though..
It might cause problems with annex.pidlock, if every git-annex
process starts taking a shared lock, because pidlock does not support
shared locks, so only 1 git-annex process will be able to run, perhaps in
situations where multiples can run now even with pidlocking because no
locking is needed.
Also, the existing locking machinery runs in the Annex monad, but such a
lock needs to be implemented in Annex.hs itself, so that would be a
recursive dep. And, it would add overhead to every git-annex process.
(A small amount.)
Alternatively, there could be a top-level lock file that is held shared
whenever locking content files. And the v10 upgrade takes an exclusive
lock. But this seems to fail when a v9 process is running -- if it blocks
on the shared lock for the v10 upgrade, it would still go on the lock in v9
mode in the now v10 repository.
"""]]