Nicely phrased. Random input into this:
* `git rerere`. Your remark about "merge context" is what rerere is for: it remembers how you resolved a conflict. I don't know if this would apply to queuesync, but it's worth thinking about. * Depending on one's data representation, an early conflict isn't necessarily a deal-breaker. For example, a folder rename doesn't change its GUID. A pathname representation of folders will be painful here, just like in a folder move, but a structural representation has no issue -- a name change for a folder is a non-overlapping change wrt changes to its children. (A structural representation only hits difficulty when a guid-change has occurred, which only occurs in a content-based merge in which local dupes are found, at which point we're deep in conflict-Mordor anyway, and we're merely trying to do the best we can.) * There are really two different kinds of merge that we'll face: 1. Content-based, where you try to merge two heads with no shared parents, or try to reconcile potential duplicates within branches during a divergent change-based merge. This would be the situation in a first sync, but could also arise in the situation you outline -- extended offlining in which the shared ancestor has been discarded. 2. Change-based, where you have clear histories on both sides. It's worth bearing in mind the situations in which one has more trouble than the other, and when to switch. For treesync: * Quite probably the local changes will not be a long sequence of commits, but it doesn't matter much. * The parent folder rename will be the only conflict; structurally, folder A == folder B == folder C. The inserts are congruent. The analogous problem in treesync, I think, is: * Device A: add folder "Foo", children "bar", "baz", GUID AAAA * Device B: add folder "Foo", children "bar", "baz", GUID BBBB * Device B: add child "noo". * Device B syncs, reconciles the two "Foo" folders structurally, has to compose a new tree with "noo". But that's not a problem for three reasons: 0. This is really stretching the boundaries of what users will do, and I'm not too concerned with making this experience excellent at the expense of added complexity. 1. We wouldn't necessarily have two commits locally; we'd have one, and would structurally reconcile "Foo" with new child -- we'd never have to rewrite a commit. (That's switching one problem for another.) If we do have two commits locally, then A and B directly match for Foo, and then... 2. ... we have an explicit structure to work with, when a GUID changes we already have a complete structural linear history (including into the future!) that's relatively easy to change and keep consistent; we can walk forward in time to do the rewrite, or we can track a translation table and do it as we go. Happy to have you poke holes in this; it's pretty off-the-cuff. -R On 7 Aug 2013, at 3:58 PM, Nick Alexander <[email protected]> wrote: > 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 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
