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:
We need to record updated onto rev instead of guessing it in pushrebase replayer.
I will not land this diff until mononoke db schema is update D12923144, D12997125
Reviewed By: quark-zju
Differential Revision: D12922833
fbshipit-source-id: 11c6411c392ca9092be53ffba8baa074faf3a996
Summary:
This makes tests closer to production setup and removes a bunch of "saved
backup bundle to ..." messages.
With D9236657, this should not hurt server-side performance.
Unfortunately a lot tests cannot be migrated easily, mostly because revision
numbers are used. They are left with a TODO.
Reviewed By: DurhamG
Differential Revision: D9237694
fbshipit-source-id: c993fce18f07aba09f6d70964e248af8d501575a
Summary:
At the moment they are not recorded because setrecordingparams may not be set
before hooks are called.
Also hooks weren't recorded because pushrebasereplacements weren't correctly
set and KeyError was thrown. This diff fixes it
Reviewed By: quark-zju
Differential Revision: D10147933
fbshipit-source-id: ef33d3e4efa7f3c42e7fcc22ee5f6e54068bf1dc
Summary:
In D10023543 stackpush was added, and conflict check can happen earlier. In
that case failed pushrebase wasn't recorded. This diff fixes it.
Reviewed By: quark-zju
Differential Revision: D10119679
fbshipit-source-id: ef12e00a43375151f81a95eec2d9f02db0a9b12b
Summary:
The fast path avoids recreating the bundlerepo in the critical section, which
is like a reliable 0.8s win.
See the docstring in stackpush.py for details. It does not replace all use cases
that the old code path supports. So the old path is preserved.
Since it's a drop-in replacement, make it the default.
Reviewed By: phillco
Differential Revision: D10023543
fbshipit-source-id: eaceb9ae5067ab9040aa10cc65170ae54abd3331
Summary:
It was trying to add a recording for non-pushrebase pushes. It did not result
in failure, but it did result in an annoying warning.
Reviewed By: farnz
Differential Revision: D9570530
fbshipit-source-id: de999a60c146cc49a1a5fd057b6037cf9f73e367
Summary:
This change fixes two problems in pushrebase recording, that will be used to test mononoke pushrebase:
- record correct `repo_id`, it used to be always 0
- `ontorev` truncation, as we store rev as hex string we need 40 bytes instead of 20
Reviewed By: ikostia
Differential Revision: D9398009
fbshipit-source-id: 91add2d75fbb9acf32b99dc952c467d44c2ccbc9
Summary:
If pushrebase.enablerecording and the rest of the parameters are set then let's
save pushrebase requests. It involves saving the changegroup and treemanifest
bundles2 parts to bundlestore, and then inserting an entry into the database
Reviewed By: quark-zju
Differential Revision: D8801602
fbshipit-source-id: bea4f798daa8542541c8d7c4c2a051c8583930a0
