Tracking v7 progress toward becoming the default.

step 1: release

step 2: default for new repositories that used to use direct mode

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/

On Windows Subsystem for Linux, adusted branches don't work due to some problem with sqlite, so upgrading a direct mode repo there would be a problem. http://git-annex.branchable.com/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/ But, regular v5 and v7 repos do work in WSL.

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.

When not using unlocked files, the only significant difference is that Annex.Content in v7 reads and writes to the keys database. So any problem with the database code could prevent using git-annex.

There are also some slight performance differences, but they go both ways, for example the pre-commit hook is faster in v7 than v5, but v7 runs git diff in reconcileStaged.

A concern is that 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 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.

all now done