Hello sync-dev,
This is intended for warner, ckarlof, and rnewman; but, I see no reason
why others shouldn't chime in.
The merge scenario that most concerns me (right now) is the case when
(to borrow git terminology) you're rebasing a long series of commits
onto an upstream head that has advanced from your head, and the first
commit has non-trivial conflicts. In git, you need to manually update
each subsequent commit in the series to rebase.
If I understand the queue sync proposal correctly, the merge algorithm
will also consider each subsequent commit in order and need to rebase
each. For example:
* if the local commits to rebase onto upstream are
rename folder A to folder B at time t0
insert bookmark X into folder B
* if the new upstream commits are
rename folder A to folder C at time t1 > t0
insert bookmark Y into folder C
insert bookmark Z into folder C
* then presumably the merged commits should look like
rename folder A to folder B (since t0 < t1, B "wins")
insert bookmark X into folder B
insert bookmark Y into folder B
insert bookmark Z into folder B
The point being that /both/ the Y and Z inserts need to be rebased into
folder B, since each commit is a delta (roughly corresponding to a DB
crud operation) that implicitly references its "surrounding context".
As the sequence of deltas grows longer, this requires tracking more and
more merge context. (For example: renaming the same folder many times
in sequence. One can imagine coalescing renames and other local
optimizations, but this is not driving down complexity.)
Is my understanding of how this would work in queue sync correct? Am I
making this too complex? Am I missing something?
Full disclosure: I'm not clear on how this merge would look in tree
sync. I'm going to try to sketch that out right now!
Best,
Nick
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
