3 ms·
> The problem I'm referring to isn't conflict resolution, but rather spurious re-creation of files that have been deleted. That is conflict resolution, over th
by sedachv 7y ago
> The problem I'm referring to isn't conflict resolution, but rather spurious re-creation of files that have been deleted.
That is conflict resolution, over the set of files. Which is why Unison provides the "reconciling changes" UI.
> Which implies you need to choose one node from {A,B,C} that is the most likely to be available to sync the other two to.
Yes, that is a way to avoid update conflicts.
> IMO a topological sort would be an even stricter requirement than spanning tree, in that if one node becomes available, you can't sync anything "below" it!
Yes, it is also a way to avoid update conflicts.
> (eg I use unison for maildir).
Why? IMAP already takes care of synchronization, without any potential problems.
- mindslight 7y agoEh, we can disagree on a precise definition of abstract "conflict resolution", but I'm referring to unison's behavior with -batch. There's no logical conflict that needs to be resolved by user choice or algorithm. When looking at the larger system of all the replicas, unison's behavior is to simply undelete a file that was explicitly deleted. > Why? IMAP already takes care of synchronization, without any potential problems. Less configuration, less attack surface. Sharing mail over NFS is a common thing, and I view unison as a type of distributed filesystem.