Summary:
With lazy changelog, for every commit hash that is unknown to the repo, it
needs to be resolved remotely. For commit hash that is also unknown to the
remote server, it can be bad because we don't have cross-process negative
caching and will trigger the remote resolution over and over. Practically,
the solution is to avoid remote lookup if the "minor" correctness issue
is acceptable (ex. D29111710 (ac6c6cf3fa), D29114049 (880b5c3cd8)).
That has been tricky to debug - the remote fetching happens in Rust, and
cannot be easily inserted something like `import ipdb; ipdb.set_trace()`
like Python. I have been inserting sleeps and use gdb to understand the
call stack when writing the above 2 diffs.
This diff makes debugging easier by supporting "break point" setting by
environ variables. So one can do something like:
$ EDENSCM_LOG=dag::protocol=debug hg ...
DEBUG dag::protocol: resolve names [435c235d65ccc4f95595d74478a617450c96c2e] remotely
$ EDENSCM_DISABLE_REMOTE_RESOLVE=435c235d65cc4f95595d74478a617450c96c2ec hg ... --traceback --debugger
Reviewed By: andll
Differential Revision: D29404057
fbshipit-source-id: d8a631f279f32e2ee88f097796cdc85d8ca27b77
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h> or use cpython) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths
entrirely in native code, we'll want to limit our dependency on Python, which is
why this barrier exists.
See also hgext/extlib/README.md, mercurial/cext/README.mb.
How do I choose between lib and extlib (and cext)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib (if it's only used by extensions) or
mercurial/cext (if it's used by extensions or core).