20741b1eb4
* Automatically convert direct mode repositories to v7 with adjusted unlocked branches and set annex.thin. * init: When run on a crippled filesystem with --version=5, will error out, since version 7 is needed for adjusted unlocked branch. * direct: This command always errors out as direct mode is no longer supported. * indirect: This command has become a deprecated noop. * proxy: This command is deprecated because it was only needed in direct mode. (But it continues to work.) Also removed mentions of direct mode throughough the documentation. I have not removed all the direct mode code yet.
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
|
|
|
|
## 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/>
|
|
|
|
done
|
|
|
|
## 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.
|