From 933bc5c917d6bcfbb80eeeff1c3f094b70120e51 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 5 Oct 2016 16:29:32 -0400 Subject: [PATCH] Support using v3 repositories without upgrading them to v5. An easy change now that supportedVersions is a list. Since v3 and v5 are identical other than version number, just add v3 to the list. This commit was sponsored by andrea rota. --- Annex/Version.hs | 2 +- CHANGELOG | 1 + ...x_get_fails_from_read-only_filesystem.mdwn | 3 ++ ..._864d4b5c207dce19d017b3e7608531f8._comment | 52 +++++++++++++++++++ doc/future_proofing.mdwn | 8 +++ doc/upgrades.mdwn | 4 ++ 6 files changed, 69 insertions(+), 1 deletion(-) create mode 100644 doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment diff --git a/Annex/Version.hs b/Annex/Version.hs index 7726840dec..6fdc2c703b 100644 --- a/Annex/Version.hs +++ b/Annex/Version.hs @@ -22,7 +22,7 @@ latestVersion :: Version latestVersion = "6" supportedVersions :: [Version] -supportedVersions = ["5", "6"] +supportedVersions = ["3", "5", "6"] versionForAdjustedClone :: Version versionForAdjustedClone = "6" diff --git a/CHANGELOG b/CHANGELOG index f87cdf3f25..dd9b2cba7f 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -25,6 +25,7 @@ git-annex (6.20160924) UNRELEASED; urgency=medium - git-annex adjust when a large file was checked into git directly * When auto-upgrading a v3 remote, avoid upgrading to version 6, instead keep it at version 5. + * Support using v3 repositories without upgrading them to v5. -- Joey Hess Mon, 26 Sep 2016 16:46:19 -0400 diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn b/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn index 18b446ee1c..c6d0710d11 100644 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn +++ b/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn @@ -25,3 +25,6 @@ annex.version = 3 in the remote [[!tag confirmed]] [[!meta title="read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote"]] + +> [[done]]; Fixed for V3 mode and rejected trying to support all old +> versions without a repo-changing upgrade process. --[[Joey]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment new file mode 100644 index 0000000000..25464816ed --- /dev/null +++ b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment @@ -0,0 +1,52 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 7""" + date="2016-10-05T20:29:56Z" + content=""" +I've made V3 repositories be supported to use without an upgrade, so +that fixes the specific case this bug report was filed about. + +---- + +I do not, however, want to commit to git-annex supporting use of all past +repo versions without an upgrade process. The point of the upgrade process +is to keep code complication down. + +All the code that knows about V1 is in Upgrade.V1, and the rest of +git-annex does not need to check the repo version when doing things +with annex objects in order to support the different V1 location. +Supporting accessing content from V1 repositories without an upgrade would +lose this clean separation and complicate an unknown number of places in +git-annex. And any of those places that would have to include a check to +handle V1 would be liable to break as the code was changed, without anyone +except the rare V1 user likely to notice. + +V1 was the last upgrade to change the locations of annexed objects, and +there's now the tuning interface that might be used for such future +location changes, but that's not the only kind of change that an upgrade +might deal with, and making a commitment that all future versions of +git-annex will support getting annexed objects from V5 (and V6 and V3) +would really narrow down the kinds of changes that could ever be made to +the git annex repository format, and I don't want to do that. + +Supporting upgrades from all past versions is sufficient for future +proofing. It doesn't guarantee super easy use of an old repo from some old +version of git-annex. + +... You might have to copy it from its original rusty +media to some tiny corner of a far-future storage crystal, in order for +git-annex to be able to write to the repository when it upgrades to V7 +without disturbing the original rusty media. + +.. And git-annex may need to do arbitrary amounts of work, since V7 turned +out to also entail a switch from the broken-in-2100 SHA2 to a new +quantum-computer-safe hash. + +.. And git may also need to do similar work to upgrade the old repository +from the (broken-in-2010) SHA1 to its new hash. (Hopefully git will support +upgrading from old repo versions at least as well as git-annex does!) + +The important thing is to have a upgrade path that is guaranteed to +be supported all the way into the future, and I've made the best choices I +can to ensure that. +"""]] diff --git a/doc/future_proofing.mdwn b/doc/future_proofing.mdwn index e5bc89829c..71a1b4a09c 100644 --- a/doc/future_proofing.mdwn +++ b/doc/future_proofing.mdwn @@ -37,6 +37,14 @@ problem: another clone of the repository. Even if the filenames are lost, it's possible to [[tips/recover_data_from_lost+found]]. +* What about upgrades to the git-annex repisitory format? + git-annex supports [[upgrades]] from all previous repository versions, + and will always support upgrading from all of them to any new versions. + Note that the upgrade process needs to modify the content of the + repository -- if modifying the original archived repository is not + desirable you can always make a copy of the repository and upgrade the + copy. + * What about encrypted special remotes? A [[fairly simple shell script using standard tools|Decrypting_files_in_special_remotes_without_git-annex]] (gpg and openssl) can decrypt files stored on such diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn index f3646a46b4..4cf77a487a 100644 --- a/doc/upgrades.mdwn +++ b/doc/upgrades.mdwn @@ -41,6 +41,10 @@ already have git conflicts in your repository or between repositories. Upgrading a repository with conflicts is not recommended; resolve the conflicts first before upgrading git-annex. +The upgrade process needs to write to the repository. If the original +repository cannot be written to (due to eg being on readonly media), +the upgrade would need to be run in a copy of the repository. + The upgrade events, so far: ## v5 -> v6 (git-annex version 6.x)