mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'v7-default'

Browse source
This commit is contained in:
Joey Hess 2019-09-12 13:47:55 -04:00
commit eae5e96473
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
65 changed files with 448 additions and 794 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/cloning_direct_mode_repo_over_http.mdwn
View file

@ -34,3 +34,5 @@ the direct mode database either way!
--[[Joey]]
[[!meta tag=deprecateddirectmode]]
> direct mode has been removed, so [[done]] --[[Joey]]

30
doc/todo/sqlite_database_improvements.mdwn
View file

@ -52,13 +52,21 @@ process.
> solve the encoding problem other than changing the encoding
> SKey, IKey, and SFilePath in a non-backwards-compatible way.
>
> (Unless the encoding problem is related to persistent's use of Text
> internally, and could then perhaps be avoided by avoiding that?)
> Probably the encoding problem is actually not in sqlite, but
> in persistent's use of Text internally. I did some tests with sqlite3
> command and it did not seem to vary query results based on the locale
> when using VARCHAR values. I was able to successfully insert an
> invalid unicode `ff` byte into it, and get the same byte back out.
>
> The simplest and best final result would be use a ByteString
> for all of them, and store a blob in sqlite. Attached patch
> shows how to do that, but old git-annex won't be able to read
> the updated databases, and won't know that it can't read them!
> Unfortunately, it's not possible to make persistent not use Text
> for VARCHAR. While its PersistDbSpecific lets a non-Text value be stored
> as VARCHAR, any VARCHAR value coming out of the database gets converted
> to a PersistText.
>
> So that seems to leave using a BLOB to store a ByteString for
> SKey, IKey, and SFilePath. Attached patch shows how to do that,
> but old git-annex won't be able to read the updated databases,
> and won't know that it can't read them!
>
> This seems to call for a flag day, throwing out the old database
> contents and regenerating them from other data:
@ -90,15 +98,9 @@ process.
> out of the way won't do; old git-annex will just recreate them and
> start with missing data!
>
> And, what about users who really need to continue using an old git-annex
> and get bitten by the flag day?
> And, what about users who use a mix of old and new git-annex versions?
>
> Should this instead be a annex.version bump from v7 to v8?
> But v5 is also affected for ContentIdentifier and Export and Fsck.
> Don't want v5.1.
>
> > Waiting until v5 is no longer supported and including this in v8
> > seems the only sure way to avoid backwards compatability issues.
> Seems this needs an annex.version bump from v7 to v8.
----

11
doc/todo/v7_path_toward_default.mdwn
View file

@ -2,12 +2,8 @@ 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
@ -30,8 +26,6 @@ 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.
done
## step 4: default for all new repositories
Could probably happen fairly soon after switch of direct mode.
@ -42,8 +36,6 @@ avoids the problems discussed in step 5.
## step 5: automatic v5 to v7 upgrades
`v7-default` branch in git has this.
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.
@ -87,3 +79,6 @@ and so is blocked on v5 auto-upgrading.
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]]

4
doc/todo/wishlist__58___pack_metadata_in_direct_mode.mdwn
View file

@ -3,3 +3,7 @@ The metadata storage for direct mode (V3) is this. In directory .git/annex/objec
It would be great if these files are packed, maybe also in the git pack files format.
[[!meta tag=deprecateddirectmode]]
> direct mode has been removed. Its replacement, v7 unlocked, does use a
> sqlite database that packs all the metadata in one place. [[done]]
> --[[Joey]]