-
-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge: complete rewrite #301
Conversation
0f40358
to
bb428b8
Compare
af3dc23
to
f6a2151
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I'm able to follow, this looks good. I'm still slow at reading typescript and I don't know these codepaths well, but nothing jumped out at me as being wrong.
type: "edition", | ||
props: computeDiff(origin, current, [ | ||
"type", | ||
/*"portalId",*/ // unlikely because we don't swap marker yet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we'd added (or were planning on adding) maker swap
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"yet", also what swaping marker does has to be defined first,
preserving the link ID on anchor swap allow to track anchor and resolve situation where one moved an anchor while another assigned it
imo, marker don't need this refinement and can change ID on swap
} | ||
return this.localchanged; | ||
} | ||
|
||
mergeZones(op: WasabeeOp) { | ||
const ids = new Set(); | ||
const ids = new Map<ZoneID, WasabeeZone>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes!
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), thefollower
(local) and the ancestororigin
that was saved inlocal
data at last fetch.The merge is structured in 4 steps:
masterChange
: difference betweenmaster
andorigin
(what's new on the server)followerChange
: difference betweenfollower
andorigin
(what did I changed or fb event changed)followerChange - masterChange
: compute what are the local changes that are not onmaster
conflict may arise: we change smth that is not on
master
anymore, we change something both onmaster
andfollower
etcmaster
andfollower
versionmaster
what 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.