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.

* WSL has such a problem currently,
  but it doesn't seem to affect using v7 repos, only adjusted branches.
  <http://git-annex.branchable.com/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/>
* A 2016 bug reported the keys database not working on lustre,
  presumably due to sqlite needing part of POSIX that lustre does not provide
  or something.
  <http://git-annex.branchable.com/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/>

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]]