Collaborative Document Updates
In Notion, every collaborator sees all changes at all times because it is a central server. In Seed, when a collaborator starts writing, he doesn't have the latest state of the document until the rest of the collaborators show it up.
The backend could offer an API with the list of conflicts. @z6Mks...ESQGx @z6Mkg...A7cgt @z6Mkq...RcgWp @z6Mkj...d4w8w @z6Mkn...SWigo
Type of Conflicts
Automatic Resolution Rules are based on the principle of Last write wins.
What version wins? Alice or Bob's version?
Blocks remove, move, edit.
Merge and Rebase are different. Here, we are talking about Rebase.
What diffing are we doing?
A. Alice draft versus Bob document.
B. Alice rebased draft versus Bob document.
Merge problems: It is not possible to apply operations to the rebase.
Automatic conflict resolution with fallback.
Adding Blocks to the same document level.
* There is only a conflict if the two users add the blocks to the same place.
1.
Alice publishes a document with 5 blocks.
2.
Alice creates a draft based on this document.
3.
Bob publishes a document with 2 more blocks below Alice's.
4.
Alice adds 2 more blocks to the draft.
5.
Alice is notified that Bob has published a new version.
Rule: Last Timestamped Version appends blocks to the Level.
Remove and Edited the same block
Steps:
1.
Alice publishes a document with 5 blocks. v1
2.
Alice creates a draft of this document. v1a
3.
Alice edits the last block in the draft.
4.
Bob removes the last block and publishes the new version. v2
5.
Alices is notified that Bob has published a new version.
6.
Alice rebases the draft to last version. v2a
Rule: Edited block is not deletion.
Remove and Edited the same block
Steps:
1.
Alice publishes a document with 5 blocks.
2.
Alice craetes a draft of this document.
3.
Bob edits the last block a publishes the document.
4.
Alice deletes the last block in the draft.
5.
Alice is notified that Bob has published a new version.
Rule: Edited Block is deleted.
Rebasing Scenarios
The Rebase Context occurs when the user opens a draft and a collaborator creates a new update; thus, the document state changes.
Scenario 1: Same block edited by more than one Collaborator
1.
Alice changes Block2
2.
Bob's draft changes Block2
3.
If Bob rebases, Bob's change wins and will override Alice changes.
What does Bob want?
1.
Bob doesn't want to override Alice's changes. Bob needs to merge conflicts manually.
2.
Bob wants to override Alice's changes. Bob just rebases.
Scenario 2: A block is removed by one Collaborator and edited by other
Scenario 3: A block is moved by one Collaborator and edited by other
Scenario 4: more than 2 conflicting versions
Automerge Scenarios
The Automerge Context occurs without a new draft. You published a new version, and a collaborator has created a later version. We might want the same diffing view as in Rebasing Scenarios.
Scenario 1: Concurrent Updates.
What do we want to show if there are collaborative concurrent updates? The problem with concurrent updates is that none of the collaborators have seen the other collaborators' changes before publishing theirs.
This is a problem when the same blocks are involved, aka if there are conflicts. Conflicts State will happen. The problem is how collaborators will solve them.
Options:
1.
We show an automerge view of all versions. Collaborators can talk and coordinate. One Collaborator can navigate the version list to rescue removed changes and resolve the conflicts as agreed by the group.
2.
We show a diff view of the possible conflicts. Collaborators talk and coordinate. One Collaborator goes to a diff view and manually accepts each conflict.
The better option will depend on the rate of success of the automerge conflict resolution. How many times do the collaborators need to go back to document history and restore changes?
Powered by Mintter + The Hypermedia Protocol