liking this solution pretty well
This commit is contained in:
parent
0ba7f2ec91
commit
8add0ec60e
1 changed files with 28 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue