No description
dd984e150a
Moving an aggregate to a different endpoint is the sharpest failure mode in the design, so it is a command rather than something a config edit triggers: sync already refuses on target drift and points here. The move settles against the old target first. An event a user created in the aggregate and that has not yet reached a sink exists only there, and would be lost the moment we stop looking at that calendar. Only then is every mapped event rebuilt on the new target — a rewrite rather than a copy, since the rendered content differs between backends that can and cannot suppress scheduling. Orphans on the old target are kept unless --purge-old, and a purge is bounded by the derivation, so events the user keeps in that calendar themselves survive. Also fixed prepare_vdirs, which created a directory per endpoint. That told pimsync a local collection existed before its remote counterpart had been seen, so it tried to create the counterpart: unsupported for a read-only feed, and it would have invented calendars on a CalDAV server. Only the vdir root is created now; collections are pimsync's to make from what it discovers. One test premise was wrong rather than the code: a foreign event in an aggregate that has a sink is a user-created event and gets adopted into that sink, so it never reaches a purge as an outsider. Both behaviours are now covered. Verified against the live Posteo calendar after the change: still a clean no-op. 106 tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| src | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| devbox.json | ||
| devbox.lock | ||
| SPECS.md | ||
| TODO.md | ||