How to configure Unison for real peer-to-peer?

Question

I have a handful of devices, and am considering keeping them in sync with Unison.

The devices are not running all the time, they are switched off a few hours per day, not necessarily at the same time. None of the devices is running 24 hours a day. So I need real peer-to-peer, for instance see how a change (marked as *) propagates from A to B,C,D even though none has been running during all syncs:

A-on*   B-on    C-off   D-off
A-on*   B-on*   C-off   D-off
A-off*  B-on*   C-off   D-off
A-off*  B-on*   C-on    D-off
A-off*  B-on*   C-on*   D-off
A-off*  B-off*  C-on*   D-off
A-off*  B-off*  C-on*   D-on
A-off*  B-off*  C-on*   D-on*

Unfortunately, the Unison user manual recommends a star topology for more than 2 machines:

Using Unison to Synchronize More Than Two Machines

Unison is designed for synchronizing pairs of replicas. However, it is possible to use it to keep larger groups of machines in sync by performing multiple pairwise synchronizations.

If you need to do this, the most reliable way to set things up is to organize the machines into a “star topology,” with one machine designated as the “hub” and the rest as “spokes,” and with each spoke machine synchronizing only with the hub. The big advantage of the star topology is that it eliminates the possibility of confusing “spurious conflicts” arising from the fact that a separate archive is maintained by Unison for every pair of hosts that it synchronizes.

Despite that, is there any way to achieve real peer-to-peer with Unison?

Answer 1

I have always used Unison in a star topology to synchronise my four machines. The reason for this is that it is not a versioning file system (like git for example), but rather a synchronisation tool.

If you do opt for a distributed topology (which you will have to set by creating a configuration file for each device and synchronising all), you will undoubtedly end up doing a large amount of manual conflict resolution, which will be grim. This will certainly be the case unless you make only extremely basic changes to the files on the system and only on one device at a time.

So, suggestions:

1. Rent a cheap virtual server with enough storage space for the data that you want to synchronise.
2. Try the distributed topology and see whether it causes too many problems to be usable.

Answer 2

Unison is intrinsically peer-to-peer. This is precisely why a star topology is recommended: the tool does not have any notion of central server, so it's up to the user to enforce one.

You can certainly use Unison in a peer-to-peer way, but there's no miracle: for every pair of machines (A,B), you need to pick one of the machines (say A) and create a profile for synchronization with B. So if you have n machines, you'll need n*(n-1)/2 profiles.

In addition to requiring a lot of profiles, you're likely to end up with conflicting changes. This is an intrinsic problem with your requirements. In particular, your network can become partitioned: if you end up with D1 = D2 ≠ D3 = D4, you have a conflict between {D1, D2} and {D3, D4}; if you reconcile that conflict by synchronizing D1 with D3, you'll end up with a new version on D1 and D3, and different old versions on D2 and D4: the mess tends to spread.

If you really want to go purely peer-to-peer, I recommend using a tool that maintains history and is good at merging, such as git. Even there, a star topology (i.e. a central repository) is best, because it provides a place which has the authoritative latest version. But if you don't have a central repository, and thus your history is prone to generating conflict, at least git will give you better tools to record merge histories so that you can see what parts are conflicting (which helps a lot when you're trying to resolve the conflicts).