You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A scenario was described during development of "resolve conflicts" PR #725:
the _local_update signal of the MagicFile state-machine goes from _conflicted -> _conflicted without doing anything
should we queue a LocalSnapshot, or is the user editing the file to ultimately resolve the conflict?
what if a remote party resolves the file meantime, and so we get an incoming update that is also a resolution?
(Could immediately re-conflict with the contents of the local edit -- that is, have a LocalSnapshot ready to go, apply the remote resolve but then produce a new conflict (hang on, we can't "produce a conflict" -- the other side has generated their new version) -- so yeah if we produce a LocalSnapshot at this moment, we could ensure its parent is our version before the incoming resolve (makes sense) and thus this is seen as a conflict by all parties)
That last thing might be the most-correct. That is:
continue to do nothing when we're conflicted and see a local change
_if_we get an incoming resolve while conflicted AND we have changed local contents, then:
queue a LocalSnapshot (with our current latest version as the parent, not the incoming resolve)
produce a new conflict locally (preserve "our" contents, write the resolution into conflict-marker
when our snapshot is uploaded, all other participants will see this as a conflict (I think?? right?)
...maybe the user completes editing the file and deletes the conflict-markers before any incoming resolution appears; this means we just create our own conflict-resolution Snapshot
The text was updated successfully, but these errors were encountered:
A scenario was described during development of "resolve conflicts" PR #725:
_local_update
signal of theMagicFile
state-machine goes from_conflicted -> _conflicted
without doing anythingLocalSnapshot
ready to go, apply the remote resolve but then produce a new conflict (hang on, we can't "produce a conflict" -- the other side has generated their new version) -- so yeah if we produce a LocalSnapshot at this moment, we could ensure its parent is our version before the incoming resolve (makes sense) and thus this is seen as a conflict by all parties)That last thing might be the most-correct. That is:
LocalSnapshot
(with our current latest version as the parent, not the incoming resolve)The text was updated successfully, but these errors were encountered: