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.

diff --git a/Annex/Version.hs b/Annex/Version.hs
index 7726840decc51713c3ae3307d3bfca7364fe3ba4..6fdc2c703be4d53f0ac5ec784740597809b782ae 100644 (file)
--- 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 f87cdf3f25d2adef750bfa28d7d5c2fe2f1f86f6..dd9b2cba7f94213445512fed32244e7afe168787 100644 (file)
--- 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 <id@joeyh.name>  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 18b446ee1cc4b6a03763d5dc161b53989cb1a6f0..c6d0710d1122d12f854959801fe0a4bdb648b3ac 100644 (file)
--- 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 (file)
index 0000000..2546481
--- /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 e5bc89829ca54c94330e43c9922ff51f5f5a2b57..71a1b4a09c630c2759897e05a03c936f368703b4 100644 (file)
--- 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 f3646a46b47aac6797406e83c96719e027ef9373..4cf77a487a1d40a1aea20842f8754f9ce3c6ed10 100644 (file)
--- 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)