https://bz.mercurial-scm.org/show_bug.cgi?id=5481

            Bug ID: 5481
           Summary: With aggressivemergedeltas=False, one merge parent is
                    ignored for delta generation even if the other parent
                    is unsuitable
           Product: Mercurial
           Version: default branch
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: Mercurial
          Assignee: bugzi...@mercurial-scm.org
          Reporter: gabor.stefa...@nng.com
                CC: mercurial-de...@selenic.com

The algorithm for finding the right delta base for a merge is subtly wrong when
aggressivemergedeltas is False. We pick the higher-numbered of the two merge
parent revisions, check if it produces a viable delta, and if not, we fall back
straight to a rev-1 delta without ever looking at the other parent.

In a merge, one of the parents is typically an excellent candidate for the
delta base, while the other may be no worse than a random revision. It's
difficult to predict the optimal parent without actually calculating the deltas
for both.

Since we chose against making aggressivemergedeltas the default, we can't
always guarantee an optimal parent choice. However, there is room for
improvement:
- We select the parent to use based on revision number, or "tipmostness". This
is not a good predictor of which parent is optimal - indeed, in a pull request
scenario, it tends to select the "incoming" parent, which may have branched out
far in the past, and is a rather poor delta base candidate. Instead, we should
compare the DAG distances from a common ancestor, and pick the larger one as
the delta parent.
- If the selected parent turns out to be unsuitable (e.g. too long delta
chain), the other parent is still a better candidate than rev-1. We should fall
back to it, and only try rev-1 if we have exhausted both parents. This behavior
is still different from aggressivemergedeltas, as it accepts the first tested
parent to give a good delta, and only moves on to the other one if the first
delta is rejected, as opposed to always generating both deltas and picking the
smaller one. So, the performance hit should be negligible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to