Replies: 2 comments 2 replies
-
#131 used to be about that weird error, which is where I discovered that The implicit local sync server was a deliberate choice. A replica doesn't actually work very well if it never syncs -- its storage grows without bound, even if tasks are deleted, as it must keep a list of every operation performed on the task list since the first. The sync process allows a replica to delete operations that have been sync'd to the server, and keep only the set of existing tasks, which is of relatively constant size. The approach is specifically designed to allow an easy migration from a single replica syncing locally into a single replica syncing remotely. You're right about the docs -- I added #156 for that. No, multiple sync servers are not supported. In the OT model, a sync server's main job is to be the arbiter of what the "current" state is, and allow step-by-step changes to that current state. If there were multiple servers, then there would be multiple "current" states with no way to disambiguate them. It'd be like having a google doc that is also an office 365 doc. I like the idea of editing the config with commands, and I think TOML has good support for that. Let's break that out into another issue. How about the following flow:
|
Beta Was this translation helpful? Give feedback.
-
I changed the discussion title to "Sync setup workflow" since this is about the client-side setup, rather than running a sync server. |
Beta Was this translation helpful? Give feedback.
-
In playing around with the MVP version of taskchampion, I encountered these issues:
I'd expect roughly the following flow for a user to set up syncing:
task sync
it would error saying "ERROR: no sync server configured, run [...] to configure sync-server address"task sync set-url [...]
or similarBeta Was this translation helpful? Give feedback.
All reactions