Please describe the problem.
Our datalad tests started to fail 2 days ago in datalad/git-annex .
one relates to the fact that git-annex, if init is provided with --version=6 would auto upgrade all the way to 10, not 8 which is the "default" version of annex:
lena:/tmp
$> mkdir r && cd r && git init && git annex init --version=6 && git config annex.version
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /tmp/r/.git/
init ok
(recording state in git...)
10
and it would stay at 8 if --version=8
$> mkdir r && cd r && git init && git annex init --version=8 && git config annex.version
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /tmp/r/.git/
init ok
(recording state in git...)
8
which makes it a bit odd.
Anyways -- thought to mention this and seek feedback so either git-annex adjusts its ways or we adjust our tests to expect annex auto-upgrade any non-default version to the highest one it supports.
What version of git-annex are you using? On what operating system?
$> git annex version
git-annex version: 8.20211231+git126-gf7a3c1355-1~ndall+1
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 8
Hmm, the git-annex-upgrade man page says "Upgrades the repository to the latest version" and v10 is the latest version now. --version=8 will do what you want. I think that people would generally be surprised if
git-annex upgradedid not upgrade to the latest supported version.As for
git-annex init --version=6, v6 is not a supported version, so that was upgrading to v8 before. The git-annex-init man page says "When the version given is one that automatically upgrades to a newer version, it will automatically use the newer version instead." and v6 does automatically upgrade to v10 now, so again this behavior is following the documentation. Although so I suppose would be using v8 in the brief amount of time v10 is not upgraded to by default.Scratch that about
git-annex init --version; v8 does not automatically upgrade to v10 yet, so why should v6? I agree that seems like a bug.fixed
v8 will remain supported for at least 1 year, probably a bit longer than that. And it will still be default in the next release, and probably next several releases on top of that.
cool, so I think there is one missing (from documentation) notion of the "default" version (in addition to "supported", "upgradeable" and "latest" which is = max("supported")). If so -- I think - the "default" version should be listed in
git annex versionas "default version:" in addition to "supported" and "upgradable" -git-annex-initman page could say "When the version given is older than default version, it will automatically use the newer default version instead." - may begit-annex-upgrademan page would say "Upgrades the repository to a supported version.", and allow for upgrade todefaultorlatest(probably get--versionoption to specify which?) with "default" being the default version to upgrade to (thus staying consistent with git-annex-init upgrading to default, not latest)?I think that might make present difference between "default" and "latest" clearer.
I think you are making this a lot more complex than it will appear to any user. These versions are almost indistinguishable by the user; v9 is literally one git config change from v8.
And also, I reserve the right to make it do anything that makes sense around upgrades. Overspecifying the behavior will constrain future upgrades. Repository upgrades often already involve threading a very fine needle, making the hole artificially smaller does not seem wise.
I suspect your test suite is unncessarily fragile around git-annex repository version numbers, perhaps that is the real root of your problem?
well, to me as a user those upgrades become immediately visible whenever older (not yet supporting v9) version of git-annex tries to operate on v9 repository (regardless how trivial the change between 8 and 9 is).
I recommended adding explicit "default" primarily because you cited man pages as the operational/design guide, and I felt that it is incomplete.
might be... although I can proudly state that may be not -- we had only 2 (out of many 100s) tests failing, so at least that check seems to be quite nicely isolated in our tests. And insofar seems have pointed to a defect in git-annex (they are all back to green, woohoo!
). Having stated that -- we might indeed want to adjust them.