Page MenuHomePhabricator

copies: do copy tracing based on ctx.p[12]copies() if configured
ClosedPublic

Authored by martinvonz on Feb 20 2019, 7:27 PM.

Details

Summary

This adds an option to do copy tracing in a changeset-optimized
way. If the metadata is stored in filelogs, this is obviously going to
be suboptimal. The point is that it provides a way of transitioning to
changeset-stored metadata.

Some of the tests behave a little differently, but they all seem
resonable to me.

The config option may very well be renamed later when it's clearer
what options we want and how they will behave.

When the test suite is run with --extra-config-opt to use the new copy
tracing, all tests pass, besides test-copies.t (which fails in the
same way as you can see in this patch).

hg debugpathcopies 4.0 4.8 reports 82 copies. With this option
enabled, the only difference is this:

-mercurial/pure/bdiff.py -> mercurial/cffi/bdiff.py
+setup_bdiff_cffi.py -> mercurial/cffi/bdiff.py

I believe that happened because it was renamed in different ways on
different sides of a merge and the new algorithm arbitrarily prefers
copies that happened on p1. The runtime is about 0.85 seconds with the
old copy tracing and 5.7 seconds with the new copy tracing. That's
kind of slow, but actually better than I had expected.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

martinvonz created this revision.Feb 20 2019, 7:27 PM
This revision was automatically updated to reflect the committed changes.

When the test suite is run with --extra-config-opt to use the new copy
tracing, all tests pass, besides test-copies.t (which fails in the
same way as you can see in this patch).

For the record, I don't know what I did wrong that time, because that seems to be a lie. These tests fail:

test-status.t:
The 'Other "bug" highlight' changed and is not buggy with the new copy tracing enabled

test-mv-cp-st-diff.t:
Different debug output from the new algorithm

test-commit-amend.t:
A rename inside a merge commit is now reported. The source file existed on both sides of the merge, so I suppose the old algorithm recorded it as being from p2.