84 lines
3.5 KiB
Markdown
84 lines
3.5 KiB
Markdown
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]]
|
|
|