I’m struggling with myself to get two master copies of a repository in two different devices (group A), and other two non-master copies in other two different devices (group B). I’d like, on the one hand, group A to behave as normal repos (read/write, any change in any of them is synchronized), as if group B didn’t exist. On the other hand, the devices in group B should get the last versions from any of the devices in group B.
The draft of the solution is:
group.device.instance [of syncthing]
A.a.1: not master, connected to A.b.1
A.a.2: master, connected to B.a.1
A.b.1: not master, connected to A.a.1
A.b.2: master, connected to B.b.1
B.a.1: not master, connected to A.a.2
B.a.2: not master, connected to A.b.2
B.b.1: not master, connected to A.a.2
B.b.2: not master, connected to A.b.2
The drawback of such a setup is that it is not scalable at all, since NA*(2+NB) instances are required, where NA and NB are the number of devices in groups A nd B, respectively.
Since the master mode has been designed to be set only in a device, I think that having a slave mode (which would only read, not write to others) could fit better than extending master to groups. Depending on the implementation details, providing three types (master, normal and slave) would allow to move devices from one group to the other, without modifying multiple instances. That would also fulfill the requirement for this use case: Sync activation checkbox (repository-level)
However, I suspect that the master mode has been designed that way because of the protocol, due to the inability to look for changes without updating the global reference. Could you help me to achieve a better design for this case, or to understand the difficulty of including this feature?
Thank you for such fast and accurate responses. And congratulations for developing and improving this great tool so fast!
I feel a bit embarrassed because I didn’t search in the issue list. Sorry for that.
I read somewhere (don’t remember the thread) that help is needed to improve the documentation with "how-to"s. I’d be glad to contribute by explaining the configuration of this case and the other one I’ve asked about, after you’ve had time to properly finish and test the work in progress. Still, I have three minor questions to properly understand the new model:
Does “always override local changes” mean the user won’t be able to add new files to a local repo in “slave true” mode (because they will be automatically deleted)? Or just that modifications to existing files will be overwritten?
Will restarting the application be required for the changes to take effect?
Do these changes somehow facilitate the configuration of multiple local folders? Or is it still out of the scope of the project? (NOTE: one of the devices has two local copies, although I didn’t explain that in the example above)
My fault. I was thinking about changing a repo from “both false” to “both true”, and then, some minutes/hours later, back to “both false”. The second question refers to those (two) changes. At now, restarting is required in order to change the master flag.