diff --git a/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment b/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment index 2ddaccd98e..6e11790e16 100644 --- a/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment +++ b/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment @@ -5,22 +5,23 @@ content=""" 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. +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. 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 diff --git a/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment b/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment new file mode 100644 index 0000000000..4da9359828 --- /dev/null +++ b/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_12_fc10e403f35f47a6c4464f3f68d01eca._comment @@ -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. +"""]]