WardCunningham / Smallest-Federated-Wiki

This wiki innovates by: 1. federated sharing, 2. drag refactoring and 3. data visualization.
http://wardcunningham.github.com/
GNU General Public License v2.0
1.21k stars 188 forks source link

Ideal semantics of drag-and-drop merge #427

Open WardCunningham opened 9 years ago

WardCunningham commented 9 years ago

The pull request https://github.com/fedwiki/wiki-client/pull/52 brings drag-and-drop merging of divergent pages possible by simply consolidating the divergent journals and replaying the result. This raises the question, how should journals be combined?

The obvious choice would be to interleave actions based on dates. In my prototyping I stopped short of this because I knew dates could be wrong or even missing. It is possible to infer missing dates and the inference could have bounds based on surrounding actions. But better to try something simpler first.

Since I use a drag gesture to request the merge, I chose to add the dragged journal actions to the end of the journal upon which they were dropped (omitting duplicates, of course). This makes the merged result dependent of which way the merge was requested. If you don't like the merge, you have another way to try it. If you have three divergent pages you have many things to try.

It is possible with this simple approach to do much more delicate merges: pick earlier versions of A and B, merge them, then merge the rest of the actions in some other order.

A disadvantage of the simple approach is that dates in the journal can be out of order. Is this bad? It would seem so but what makes us think chronology is important when work has been done independently?