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
f6aa097a39
Speed up importing trees from special remotes somewhat by avoiding redundant writes to sqlite database. Before, import would write to both the git-annex branch and also to the sqlite database. But then the next time it was run, needsUpdateFromLog would see the branch had changed, so run updateFromLog, which would make the same writes to the sqlite database a second time. Now import writes only to the git-annex branch. The next time it's run, needsUpdateFromLog sees that the branch has changed and so calls updateFromLog, which updates the sqlite database. Why defer the write to the sqlite database like this? It seems that it could write to the database as it goes, and at the end call recordAnnexBranchTree to indicate that the information in the git-annex branch has all been written to the cidsdb. That would avoid the second import doing extra work. But, there could be other processes running at the same time, and one of them may update the git-annex branch, eg merging a remote git-annex branch into it. Any cids logs on that merged git-annex branch would not be reflected in the cidsdb yet. If the import then called recordAnnexBranchTree, the cidsdb would never get updated with that merged information. I don't think there's a good way to prevent, or to detect that situation. So, it can't call recordAnnexBranchTree at the end. So it might as well wait until the next run and do updateFromLog then. It could instead do updateFromLog at the end, but it's going to check needsUpdateFromLog at the beginning anyway. Note that the database writes were queued, so there is already a cidmap that is used to remember changes that the current process has made. So, omitting database writes can't change the behavior of the current process. Also note that thirdpartypopulatedimport uses recordcidkeyindb, which reflects what it already did. That code path does not use the cidmap, but does not need to query it either. It might be possible to make that code path also only update the git-annex branch and not the db, but I haven't checked. Sponsored-by: Noam Kremen on Patreon |
||
|---|---|---|
| Annex | ||
| Assistant | ||
| Backend | ||
| Build | ||
| CmdLine | ||
| Command | ||
| Config | ||
| Database | ||
| debian | ||
| doc | ||
| Git | ||
| Limit | ||
| Logs | ||
| Messages | ||
| P2P | ||
| Remote | ||
| RemoteDaemon | ||
| standalone | ||
| static | ||
| templates | ||
| Test | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .appveyor.yml | ||
| .codespellrc | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| Annex.hs | ||
| Assistant.hs | ||
| Backend.hs | ||
| bash-completion.bash | ||
| Benchmark.hs | ||
| BuildFlags.hs | ||
| BuildInfo.hs | ||
| CHANGELOG | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| COPYRIGHT | ||
| Creds.hs | ||
| Crypto.hs | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-union-merge.hs | ||
| Git.hs | ||
| Key.hs | ||
| Limit.hs | ||
| Logs.hs | ||
| Makefile | ||
| Messages.hs | ||
| NEWS | ||
| README | ||
| Remote.hs | ||
| Setup.hs | ||
| stack.yaml | ||
| Test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
git-annex allows managing large files with git, without storing the file contents in git. It can sync, backup, and archive your data, offline and online. Checksums and encryption keep your data safe and secure. Bring the power and distributed nature of git to bear on your large files with git-annex. For documentation, see doc/ or <https://git-annex.branchable.com/>