2fd27c6df5
Rather than direct mode, which this is a small step on the path to removing. Init on a crippled filesystem already used v7 adjusted branches, and like that, this doesn't pose any interoperability issues with old versions of git-annex that clone the same repo, because files are only unlocked on the adjusted branch.
70 lines
2.5 KiB
Markdown
70 lines
2.5 KiB
Markdown
Tracking v7 progress toward becoming the default.
|
|
|
|
## step 1: release
|
|
|
|
done
|
|
|
|
## step 2: default for new repositories that used to use direct mode
|
|
|
|
Done when using the command line to init in a crippled filesystem.
|
|
|
|
Done when using the assistant.
|
|
|
|
## step 3: auto-upgrade from direct mode
|
|
|
|
Direct mode is very buggy and limited, so it's easy for v7 (with adjusted
|
|
unlocked branches) to be better than it.
|
|
|
|
Note that direct mode repos with old git-annex interoperate with adjusted
|
|
unlocked repos with new git-annex, so there is no need to wait for v7 to be
|
|
widely supported.
|
|
|
|
One problem with this is that direct mode stores only a single copy
|
|
of a file, but v7 unlocked with annex.thin needs two copies if hard links
|
|
are not supported. So some users will experience the repo doubling in size.
|
|
Limited mostly to windows, also some FAT media. This seems difficult
|
|
to avoid though, see discussion in
|
|
<http://git-annex.branchable.com/todo/annex.thin_without_hardlinks/>
|
|
|
|
## step 4: default for all new repositories
|
|
|
|
Could probably happen fairly soon after switch of direct mode.
|
|
|
|
This is entirely new repositories that git-annex init is run in for the
|
|
first time (no sibling git-annex branches). Limiting to new repos
|
|
avoids the problems discussed in step 5.
|
|
|
|
## step 5: automatic v5 to v7 upgrades
|
|
|
|
Since v5 repos and v7 repos not using unlocked files are functionally
|
|
almost identical, this is unlikely to break much. Unlocking files will of
|
|
course change behavior though.
|
|
|
|
This needs to be deferred until every git-annex likely to be in use
|
|
supports v7. A v5 repository may be used by multiple
|
|
machines, some not supporting v7 and some that do. If one upgrades to v7
|
|
and starts using unlocked files, those files won't be accessible on the old
|
|
v5 machines.
|
|
|
|
> v7 is in debian stable now; oldstable (stretch) has v7 available
|
|
> as a backport but not by default, and will remain supported
|
|
> until 2022.
|
|
>
|
|
> But workflows involving unlocking and re-locking that work on v5 will
|
|
> also work on v7 and keep the repo compatible with v5. Only if some
|
|
> users commit unlocked files is v5 compatability lost, and even then
|
|
> it's easy to re-lock the file to fix compatabilityagain. So the risk
|
|
> of a too early upgrade to v7 is not very big.
|
|
|
|
Note that [[sqlite_database_improvements]] seems to need a v8 mode,
|
|
and so is blocked on v5 auto-upgrading.
|
|
|
|
## step 6: remove support for direct mode
|
|
|
|
Will simplify a lot of code.
|
|
|
|
## step 7: remove support for v5
|
|
|
|
This won't simplify much code, worth doing eventually. Once automatic v5 to
|
|
v7 upgrades happen, the remaining v5 specific code is not needed any
|
|
longer.
|