2018-10-31 12:31:07 +00:00
|
|
|
Tracking v7 progress toward becoming the default.
|
|
|
|
|
|
|
|
|
|
## step 1: release
|
|
|
|
|
|
|
|
|
|
done
|
|
|
|
|
|
|
|
|
|
## step 2: default for new direct mode repositories
|
|
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
Done when using the command line to init in a crippled filesystem.
|
|
|
|
|
|
|
|
|
|
The assistant still creates direct mode repositories though,
|
|
|
|
|
and will need to enable annex.thin and adjusted unlocked branch instead.
|
2018-10-31 12:31:07 +00:00
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
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.
|
|
|
|
|
|
2019-08-26 16:29:43 +00:00
|
|
|
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/>
|
|
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
## step 4: default for all new repositories
|
|
|
|
|
|
2019-08-26 16:29:43 +00:00
|
|
|
Could probably happen fairly soon after switch of direct mode.
|
|
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
This is entirely new repositories that git-annex init is run in for the
|
2019-08-26 16:29:43 +00:00
|
|
|
first time (no sibling git-annex branches). Limiting to new repos
|
|
|
|
|
avoids the problems discussed in step 5.
|
2018-10-31 12:31:07 +00:00
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
## step 5: automatic v5 to v7 upgrades
|
2018-10-31 12:31:07 +00:00
|
|
|
|
|
|
|
|
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
|
2019-02-20 15:28:00 +00:00
|
|
|
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.
|
2018-10-31 12:31:07 +00:00
|
|
|
|
2019-08-26 16:29:43 +00:00
|
|
|
> 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.
|
|
|
|
|
|
2018-10-31 12:31:07 +00:00
|
|
|
## step 6: remove support for direct mode
|
|
|
|
|
|
|
|
|
|
Will simplify a lot of code.
|
|
|
|
|
|
2019-02-20 15:28:00 +00:00
|
|
|
## step 7: remove support for v5
|
2018-10-31 12:31:07 +00:00
|
|
|
|
2019-08-26 16:29:43 +00:00
|
|
|
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.
|
