v7 to v8 auto-upgrade
bump version to 8 and update NEWS about it
This commit is contained in:
parent
7ed2723908
commit
3553867b66
5 changed files with 27 additions and 2 deletions
|
@ -38,7 +38,7 @@ autoUpgradeableVersions = M.fromList
|
||||||
, (RepoVersion 4, RepoVersion 5)
|
, (RepoVersion 4, RepoVersion 5)
|
||||||
, (RepoVersion 5, RepoVersion 6)
|
, (RepoVersion 5, RepoVersion 6)
|
||||||
, (RepoVersion 6, RepoVersion 7)
|
, (RepoVersion 6, RepoVersion 7)
|
||||||
-- , (RepoVersion 7, RepoVersion 8)
|
, (RepoVersion 7, RepoVersion 8)
|
||||||
]
|
]
|
||||||
|
|
||||||
versionField :: ConfigKey
|
versionField :: ConfigKey
|
||||||
|
|
20
NEWS
20
NEWS
|
@ -1,3 +1,23 @@
|
||||||
|
git-annex (8.20191107) upstream; urgency=medium
|
||||||
|
|
||||||
|
This version of git-annex uses repository version 8 for all repositories.
|
||||||
|
|
||||||
|
Existing repositories will be automatically upgraded by default.
|
||||||
|
You can prevent this, by runing: git config annex.autoupgraderepository false
|
||||||
|
|
||||||
|
There is no user-visible change between v7 and v8. However, the upgrade
|
||||||
|
process involves regenerating some sqlite databases. There are a couple
|
||||||
|
consequences of the upgrade to keep in mind:
|
||||||
|
|
||||||
|
* Any incremental fscks that were started in v7 won't resume where
|
||||||
|
they left off in v8, but will instead begin again from the first file.
|
||||||
|
* An interrupted export that was started in v7 won't resume where it left
|
||||||
|
off after upgrade to v8; files will be re-uploaded to the export remote.
|
||||||
|
* After the upgrade, git-annex will in some situations have to do extra
|
||||||
|
work while it finishes populating its sqlite databases.
|
||||||
|
|
||||||
|
-- Joey Hess <id@joeyh.name> Thu, 07 Nov 2019 13:21:11 -0400
|
||||||
|
|
||||||
git-annex (7.20191024) upstream; urgency=medium
|
git-annex (7.20191024) upstream; urgency=medium
|
||||||
|
|
||||||
When annex.largefiles is not configured, `git add` and `git commit -a`
|
When annex.largefiles is not configured, `git add` and `git commit -a`
|
||||||
|
|
|
@ -165,3 +165,5 @@ remaining todo:
|
||||||
> Alternatively, can keep the old database code and use it to read the old
|
> Alternatively, can keep the old database code and use it to read the old
|
||||||
> databases during the migration. But then bad data that got in due to the
|
> databases during the migration. But then bad data that got in due to the
|
||||||
> encoding problems will persist.
|
> encoding problems will persist.
|
||||||
|
|
||||||
|
[[done]] --[[Joey]]
|
||||||
|
|
|
@ -59,6 +59,9 @@ re-populated.
|
||||||
Any incremental fscks that were started in v7 won't resume where they left
|
Any incremental fscks that were started in v7 won't resume where they left
|
||||||
off in v8, but will instead begin again from the first file.
|
off in v8, but will instead begin again from the first file.
|
||||||
|
|
||||||
|
An interrupted export that was started in v7 won't resume where it left off
|
||||||
|
after upgrade to v8; files will be re-uploaded to the export remote.
|
||||||
|
|
||||||
After the upgrade, git-annex will in some situations have to do extra
|
After the upgrade, git-annex will in some situations have to do extra
|
||||||
work while it finishes populating the new databases. After this one-time
|
work while it finishes populating the new databases. After this one-time
|
||||||
speed cost, git-annex's speed will improve when using the new and improved
|
speed cost, git-annex's speed will improve when using the new and improved
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
Name: git-annex
|
Name: git-annex
|
||||||
Version: 7.20191106
|
Version: 8.20191107
|
||||||
Cabal-Version: >= 1.8
|
Cabal-Version: >= 1.8
|
||||||
License: AGPL-3
|
License: AGPL-3
|
||||||
Maintainer: Joey Hess <id@joeyh.name>
|
Maintainer: Joey Hess <id@joeyh.name>
|
||||||
|
|
Loading…
Reference in a new issue