zit 0.3.32 makes zit purge undo take the repository's write lock before it
restores anything, like every other command that writes the store.
No artifact, tag namespace, sync message, or on-disk repository format changed.
purge undo waits its turn
A zit repository is one append-only file, and every writer takes an
exclusive lock on it before appending: commit, clone, pull, a server
receiving a push, config and user-table writes, tags, tickets, wiki and
forum posts. Two writers that are not serialised both scan the file for its
end and both append there, so the second writes on top of the first. The
overwriting frames are complete and checksum-valid, so neither zit verify
nor crash recovery can see that anything happened: one of the two writes is
simply gone.
zit purge undo restores buried artifacts by appending them, but it opened
the store without that lock. Run while a commit, a pull loop or a server
push was writing to the same repository, from this checkout or another
worktree of the same store, either the restored artifacts or the other
writer's check-in could be lost without a trace.
It now opens the store the way every other writer does, so it waits for a concurrent writer to finish rather than racing it. The same change makes it resolve a detached worktree's store, which the old direct open did not.
The regression test holds the repository's write lock, starts
zit purge undo, and checks that the store is byte-for-byte unchanged a
second and a half later. It then releases the lock and checks that the undo
completes and the restored store verifies. Against the old code, the store
changes while the lock is held and the test fails.
Compatibility
- No on-disk repository or wire format changed; Fossil RFC revision 00 remains the target.
zit purge undonow waits, without a message, while another zit process is writing to the same repository.
Qualification
zig fmt --check, zig build test, e2e, smoke, git-import-e2e,
git-export-e2e, and dst, plus the three-runner CI battery.