The migration guide at https://git.sr.ht/~whynothugo/vdirsyncer-rs/tree/main/item/docs/content/docs/migration-guide.md and the considerations at https://whynothugo.nl/journal/2023/10/05/a-configuration-format-for-vdirsyncer-v2/ do not state, that the option conflict_resolution="a wins” is gone. Currently, if conflict_resolution is set, it must be a command.
I want to create a setup, which creates a one-way mirror of data from a CalDAV server. So when fetching data unattended, the local data is overwritten with whatever is available on the server.
Ack. It's not "removed"; I merely haven't implemented it yet.
I think https://todo.sr.ht/~whynothugo/pimsync/93 is a variant of the current case.
Is this now implemented as "conflict_resolution keep a"?
pimsync-migration.7.scd contains:
- The readonly configuration directive is not yet implemented.
but 676bd90f98538fb54a94650b884753b780b6 is “Implement the read-only directive for storages”.
As read-only is per-storage and conflict_resolution per pair, for me it is not clear how these parameter relate. Is for a read-only storage conflict_resolution ignored, if it would modify the read-only storage? Which option has higher-precedence?
I missed the outdated in the migration guide, good catch.
At the moment, the
read-onlydirective only prevents writing to a storage, but it doesn't affect change how the sync operation works. If an item would be copied from A to B, and B is read-only, the write operation is a no-op (you'll just see a warning). You can't "force copy from B to A" for this case yet.
conflict_resolution keep aonly has an effect if there is a conflict: if a single event has changed in both A and B. I think that it could also have an effect when one side is read-only, but I have to think about this approach a bit more before committing to it (I mostly want to be sure that we're not making some other use case problematic).
Side note: given that
vdirsyncerusedreadonly, I'll likely rename theread-onlydirective toreadonly.