liking this solution pretty well

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
new file mode 100644 (file)
index 0000000..2ddaccd
--- /dev/null
+++ b/doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-01-12T19:40:35Z"
+ 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.
+
+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.
+
+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.
+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?
+
+`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
+old git-annex processes running, so that might need --force.
+"""]]