This PR splits the merge feature from the operation model.
The merge feature follow a rebase mechanism using the common ancestor of the operations to be merged.
We always have a master copy (server), the follower (local) and the ancestor origin that was saved in local data at last fetch.
The merge is structured in 4 steps:
masterChange: difference between master and origin (what's new on the server)
followerChange: difference between follower and origin (what did I changed or fb event changed)
followerChange - masterChange: compute what are the local changes that are not on master
conflict may arise: we change smth that is not on master anymore, we change something both on master and follower etc
if there are conflicts (that we don't want to solve automatically), the user needs to choose for every conflicts between the master and follower version
apply on master what was previously computed and uses the resolved conflicts at step 3
The merge dialog is reworked to match the step 3.
operation.changes() is simplified to return a boolean instead of the computed changes.
This PR splits the merge feature from the operation model. The merge feature follow a rebase mechanism using the common ancestor of the operations to be merged. We always have a
mastercopy (server), thefollower(local) and the ancestororiginthat was saved inlocaldata at last fetch. The merge is structured in 4 steps:masterChange: difference betweenmasterandorigin(what's new on the server)followerChange: difference betweenfollowerandorigin(what did I changed or fb event changed)followerChange - masterChange: compute what are the local changes that are not onmasterconflict may arise: we change smth that is not onmasteranymore, we change something both onmasterandfolloweretcmasterandfollowerversionmasterwhat was previously computed and uses the resolved conflicts at step 3The merge dialog is reworked to match the step 3.
operation.changes()is simplified to return a boolean instead of the computed changes.