Status update 2026-02

Summary

It’s been a busy couple of months. I had to take some unexpected time off for personal reasons in January, followed by FOSDEM and the postmarketOS hackathon which kept me plenty busy.I’ve implemented an “interactive sync” (via pimsync sync -i), which shows a list of all operations to be performed and waits for confirmation before executing. This is especially useful when storages are in some unusual state and one wants to be certain that sync will perform the expected operations.While releases of pimsync and related libraries always depend on stable versions of dependencies, during development these often require the latest main commit of some dependency. I’ve switched to using submodules to track these, which should greatly simplify compiling pimsync for anyone who wants to try out the latest development version.Pimsync now also ships with zsh completion scripts. Writing these was actually more fun than I expected it to be. I’ve kept some tidy notes and will publish a short guide on how to write zsh completions in future. Completion scripts for other shells are welcome.Conflict resolution for properties is now implemented: when the name or description of a collection has diverged on both storages, this conflict can now be resolved. Pimsync displays a prompt with options to keep A, keep B, or manually provide a new value.The biggest change has been one-way sync. It is now possible to configure pimsync to synchronise two storages one way, effectively making B a clone of A. This required several internal refactors: I had to split out the “analyse the state of this pair” logic from “determine the new set of actions for this pair” logic. The latter is implemented via a vstorage::sync::Mode trait, so any library consumer could potentially implement their own custom logic (e.g.: sync only deletions one way, but only new items the other way).I’m happy with how this last change turned out, but somehow feel that the code can be simplified further at this point. Complexity is...