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

liking this solution pretty well

Browse source
This commit is contained in:
Joey Hess 2022-01-12 15:54:58 -04:00
parent 0ba7f2ec91
commit 8add0ec60e
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_11_e9af4784ffb84b49b6faaa21aa7c8efc._comment Normal file
View file

@ -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.
"""]]