update on status

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 2ddaccd98ed9d521b609d37d43eadc5c0c35b574..6e11790e16cfd6f8e6c4c536368a4def2c79769f 100644 (file)
--- 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.
-In v10, stop locking content files and lock separate lock files.
+lock before upgrading.
 
-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.
+In v10, stop locking content files and lock separate lock files.
 
-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 (file)
index 0000000..4da9359
--- /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.
+"""]]