A desktop version-control client built specifically for Krita's .kra art files, backed by a version-control engine written from scratch rather than wrapping Git. Git treats a .kra as an opaque binary blob and can't diff or dedup it.
Context — Krita artists have no real version control: copying .kra files by hand or bolting on git means meaningless diffs (git shows a blob changed, not which layer) and duplicated multi-hundred-MB files on every save.
Constraints — Must run entirely local (no server, no account, no cloud sync — an explicit non-goal), stay usable on modest hardware (large .kra files, HDDs, 4 GB machines), and integrate with Krita itself via a CLI the PyKrita plugin shells out to, not just a standalone viewer.
Build a version-control engine that understands Krita's tiled zip format well enough to store only changed tiles, produce a visual diff fast enough to feel instant on documents with thousands of tiles, and let an artist reconcile a parked change instead of losing it.
Wrote my own content-addressed object store with tile-level bsdiff deltas against Krita's own tile grid, rather than wrapping Git.
tradeoff → I own a lot more code (chains, packs, GC), but Git's opaque-blob model would never let me dedup or diff a .kra's internal tiles.
Delta history is split into one file per tracked file (.kvc/chains/, lazy-loaded) instead of one monolithic file rewritten on every commit.
tradeoff → More small files on disk, in exchange for commit cost that no longer scales with total repo history.
A commit adding ≥32 new objects gets bundled into one .pack file instead of one file per object.
tradeoff → On Windows, per-file creation (Defender's real-time screening) ate ~28s of a 33s initial commit. Parallelism can't hide that — the file creation itself is slow. Batching was the only fix.
commit_diff returns the capped composite image + layer metadata immediately; the expensive per-layer rasters stream in afterwards over a Tauri Channel as rayon finishes each one in parallel.
tradeoff → More IPC plumbing (streamed messages merged by layer id on the frontend) for a diff panel that paints instantly instead of blocking on the slowest layer.
Mark-and-sweep GC threads one content-hash memo through the marking pass instead of replaying each file's whole patch chain independently per commit.
tradeoff → Turned marking a long-lived repo's history from a quadratic (seconds-scale) operation into a linear one (milliseconds).
On a conflicting stash pop, instead of hard-refusing like git, I parse both .kra archives and merge at the layer level. Only layers added or modified in the stash fold into the working file, matched by layer UUID and diffed on canonicalized tile content, not raw XML — Krita rewrites volatile attributes and reshuffles tile order on every save.
tradeoff → Real complexity concentrated in merge.rs for one specific case, but it's the difference between your parked work merging in automatically and it being gone.
The whole engine sits behind a second, Tauri-free binary (kvc) that speaks JSON over stdout, rather than exposing the VCS only through Tauri IPC calls the desktop app owns.
tradeoff → A second entry point to maintain (argument parsing, a lock file so it can't race the desktop app's writes) — but it lets the PyKrita plugin commit, checkpoint, discard, and switch branches without leaving Krita. The desktop app stays the history/diff/merge surface; Krita becomes a first-class client of the same store.
