CI to automate build of cargo lockfiles on different Alpine releases for git-annex aports
https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/git-annex
1b55af4c3c
In copyFromRemote, it used to check isDirect, but that was not needed; the remote is sending the file, so it doesn't matter if the local, receiving repository is in direct mode or not. And, since the content is not present, yet, it's certianly not unlocked. Note that, the remote may indeed be sending an unlocked file, but sendkey uses sendAnnex, which will detect if the file is modified before or during transfer, and will exit nonzero, aborting the upload. So, the receiver doesn't need any checks. In copyToRemote, it forces recvkey to verify content whenever it's being sent from a v6 repository. recvkey is almost always going to verify content anyway, unless annex.verify is not set. So, this doesn't make it any more expensive, except for in that unusual configuration. The alternative would be to change the recvkey interface, so that the sender checks afterwards if what it was sending changed, and the receiver then throws out the bad transfer. That would be less expensive for the reciever, as it would not need to do a checksum verification. But, it would mean another network round trip, and since rsync closes the connection, it would need to open another ssh connection to do this. Even with connction caching, that would add latency to uploads. It would also complicate the interface, especially because an older git-annex-shell would not have the new interface available. For these reasons, I prefer punting on that at this time, and instead someone might set annex.verify=false and be unhappy that it still verifies.. (One other gotcha not dealt with is that a v5 repo could be upgraded to v6 while an upload is in progress, and a file unlocked and modified.) (Also, I double-checked Remote.GCrypt's calls to rsyncParamsRemote, and they're fine. When a file is being uploaded to gcrypt, or any other special repository, it is mediated by sendAnnex, so changes will be detected at that level and the special remote implementation doesn't need to worry about them.) |
||
|---|---|---|
| Annex | ||
| Assistant | ||
| Backend | ||
| Build | ||
| CmdLine | ||
| Command | ||
| Common | ||
| Config | ||
| Database | ||
| debian | ||
| doc | ||
| Git | ||
| Limit | ||
| Logs | ||
| Messages | ||
| Remote | ||
| RemoteDaemon | ||
| standalone | ||
| static | ||
| templates | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| Annex.hs | ||
| Assistant.hs | ||
| Backend.hs | ||
| bash-completion.bash | ||
| build.bat | ||
| BuildFlags.hs | ||
| CHANGELOG | ||
| Checks.hs | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| configure.hs | ||
| COPYRIGHT | ||
| Creds.hs | ||
| Crypto.hs | ||
| ghci | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-union-merge.hs | ||
| Git.hs | ||
| INSTALL | ||
| Limit.hs | ||
| Locations.hs | ||
| Logs.hs | ||
| Makefile | ||
| Messages.hs | ||
| NEWS | ||
| README | ||
| Remote.hs | ||
| Setup.hs | ||
| stack.yaml | ||
| Test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
git-annex allows managing files with git, without checking the file contents into git. While that may seem paradoxical, it is useful when dealing with files larger than git can currently easily handle, whether due to limitations in memory, checksumming time, or disk space. For documentation, see doc/ or <https://git-annex.branchable.com/>