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
5b4e5ce7e5
When a new file is annexed, a deletion event occurs when it's moved away to be replaced by a symlink. Most of the time, there is no problimatic race, because the same thread runs the add event as the deletion event. So, once the symlink is in place, the deletion code won't run at all, due to existing checks that a deleted file is really gone. But there is a race at startup, as then the inotify thread is running at the same time as the main thread, which does the initial tree walking and annexing. It would be possible for the deletion inotify to run in a perfect race with the addition, and remove the newly added symlink from the git cache. To solve this race, added event serialization via a MVar. We putMVar before running each event, which blocks if an event is already running. And when an event finishes (or crashes!), we takeMVar to free the lock. Also, make rm -rf not spew warnings by passing --ignore-unmatch when deleting directories. |
||
|---|---|---|
| Annex | ||
| Backend | ||
| Build | ||
| Command | ||
| Common | ||
| debian | ||
| doc | ||
| Git | ||
| Logs | ||
| Messages | ||
| Remote | ||
| Types | ||
| Upgrade | ||
| Utility | ||
| .ghci | ||
| .gitattributes | ||
| .gitignore | ||
| Annex.hs | ||
| Backend.hs | ||
| CHANGELOG | ||
| Checks.hs | ||
| CmdLine.hs | ||
| Command.hs | ||
| Common.hs | ||
| Config.hs | ||
| configure.hs | ||
| Crypto.hs | ||
| git-annex.cabal | ||
| git-annex.hs | ||
| git-union-merge.hs | ||
| Git.hs | ||
| GitAnnex.hs | ||
| GitAnnexShell.hs | ||
| GPL | ||
| Init.hs | ||
| INSTALL | ||
| Limit.hs | ||
| Locations.hs | ||
| Makefile | ||
| mdwn2man | ||
| Messages.hs | ||
| NEWS | ||
| Option.hs | ||
| README | ||
| Remote.hs | ||
| Seek.hs | ||
| Setup.hs | ||
| test.hs | ||
| Types.hs | ||
| Upgrade.hs | ||
| Usage.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 <http://git-annex.branchable.com/>