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

@@ -22,7 +22,7 @@ latestVersion :: Version
 latestVersion = "6"
 
 supportedVersions :: [Version]
-supportedVersions = ["5", "6"]
+supportedVersions = ["3", "5", "6"]
 
 versionForAdjustedClone :: Version
 versionForAdjustedClone = "6"

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
 

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]]

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.
+"""]]

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

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)