Summary:
The clients don't have any mapping from `globalrev->hash` locally but
they can do this lookup quickly using ScmQuery. We do not want to invest too
much effort on supporting globalrev based lookups on the clients as this is a
workflow we want to discourage anyway. But, for now, existing workflows may
break if this lookup is slow on the clients. Therefore, for the interim, lets
just have this lookup backed by ScmQuery. We can later improve or completely
discard this based on the future direction for globalrevs.
Reviewed By: quark-zju
Differential Revision: D15588420
fbshipit-source-id: 61f91414248ca1defe6eac4311243ee8029a92cf
Summary:
This commit just introduces a method for retrieving a mirrored
revision using the relevant ScmQuery API. The eventual objective is to use this
method to also be able to get the `hash` corresponding to a `globalrev` on the
Mercurial clients.
Reviewed By: quark-zju
Differential Revision: D15571470
fbshipit-source-id: cc0506356d27450594a690aa29a2a2a608aac5c0
Summary: See the linked task for details.
Reviewed By: quark-zju
Differential Revision: D14448505
fbshipit-source-id: fc2efa71510b718c25a2cea3acf39663d280f19a
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e