greg/mentat
1
0
Fork 0
Code Issues 294 Pull requests Projects Releases 9 Packages Wiki Activity

Add a note about the difference between rebase and merge.

Richard Newman 2017-05-05 14:54:03 +00:00
parent 8809267746
commit 5d2d7ca5c9
1 changed files with 18 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
Thoughts:-what-is-a-sync,-really?.md

@ -22,7 +22,19 @@ Improved versions of Sync began to tease these client-side stages apart:
- Two-phase application — buffering downloaded records before applying them _en mass_ — partly and temporarily separated out replication, which offers more options for detection and resolution of conflicts and inconsistencies.
- Structural/transactional record application on iOS separated out equivalence and resolution (albeit only within the scope of a sync, with no permanent record of those states.)
Mentat offers the opportunity to truly separate these:
There's another area in which Firefox Sync conflates some different things.
Firefox Sync doesn't keep any kind of historical record. To a system that does, there is a difference between:
- Establishing a new copy of an existing history (`git clone`, `git checkout`).
- Reconciling incoming changes to a linear shared history against local interim changes (`git rebase`).
- Combining two separate linear histories into a shared _state_ with an _ongoing_ linear shared history (`git merge`).
In Sync's case, the first is simply a local wipe followed by a sync. The second is a two-way merge, and so is the third: the only outcome of either is to update local and remote state to match the outcome of the merge.
Mentat offers the opportunity to separate these.
### One approach
- Replicate down remote datoms, storing them whole.¹
- Derive equivalences and new facts by comparing local and remote data. Some of this can be explicit in the datom stream (_e.g._, by describing new entities via lookup refs), and some can be schema-derived (cardinality constraints).
@ -31,4 +43,9 @@ Mentat offers the opportunity to truly separate these:
- Store appropriate assertions and retractions to record resolved conflicts. We now have a concrete, permanent record of exactly what happened during a sync!
- Commit the transaction and make it available for replication. Now other devices can also see exactly how we resolved conflicts.
### Another option
- In the case of a merge, store appropriate assertions and retractions to record resolved conflicts. We now have a concrete, permanent record of exactly what happened during a sync!
- In the case of a rebase, update local transactions to be non-conflicting, and replay them on top of the new shared state.
- Identity remapping is still necessary.
¹ The presence of cardinality and uniqueness constraints implies that this isn’t direct storage; in an RDF/OWL world, this _would_ be direct storage! However, if we squint at Mentat’s concept of a transaction — which, after all, includes states that would be invalid if the transaction were split in pieces — then we might be able to achieve this. Think about SQLite’s `PRAGMA defer_foreign_keys`.