Skip to content
This repository has been archived by the owner on Feb 14, 2018. It is now read-only.

Ideal semantics of drag-and-drop merge #427

Open
WardCunningham opened this issue Aug 4, 2014 · 0 comments
Open

Ideal semantics of drag-and-drop merge #427

WardCunningham opened this issue Aug 4, 2014 · 0 comments

Comments

@WardCunningham
Copy link
Owner

The pull request fedwiki/wiki-client#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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant