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: This will let us print more helpful/precise error messages.
Reviewed By: singhsrb
Differential Revision: D8699551
fbshipit-source-id: 060058eff925d94ffa8e6b4432c4e51bd93b2945
Summary: This configuration is set everywhere, and the spectre of stateful preprocess() functions was a Facebook-only abomination that hopefully won't reoccur. Delete this config.
Reviewed By: quark-zju
Differential Revision: D8700125
fbshipit-source-id: b5ef163f988b7bb79310275d54afea3eab2c23a2
Summary: The new logic is on at 100% without problems, so axe the old.
Reviewed By: singhsrb
Differential Revision: D8698417
fbshipit-source-id: 0126c61c7bbfa49609354415f7cc61e861c1f2d5
Summary:
D8464848 added code to invalidate merge drivers after running them, for reasons described in that diff.
But it turns out deleting from sys.modules is not enough, because Python will occasionally write a `.pyc` of the original hook, and re-use it when loading again, thus bypassing the invalidation.
This doesn't happen at all on my Mac, but happens approximately every other time when running on CentOS. Thanks to DurhamG who discovered the flakiness.
This fixes the flakiness of the test, and AFAIK this would be a problem in the wild, too, though we haven't heard of it yet.
Reviewed By: singhsrb
Differential Revision: D8675720
fbshipit-source-id: bec8fec6af9a362db1f0dd5d262932cbda6137ff
Summary:
This config has been True everwhere for a while, and seems uncontroversial. Let's fold it in everywhere as True.
This simplifies a test case.
Reviewed By: DurhamG
Differential Revision: D8578289
fbshipit-source-id: f66a6427e435d80750b4da14358c5e4f0528b6f1
Summary: This better mimics the setings we have at Facebook.
Reviewed By: DurhamG
Differential Revision: D8520441
fbshipit-source-id: d739c434195af948cadb590be26583e66ea450ea
Summary:
This is a quick bug fix for the situation xixixao discovered:
You rebase commit B onto C while having A checked out, and the rebase creates merge conflicts.
In that case, the command aborts complaining of the uncommitted changes. But, the rebasestate isn't properly removed. The user might logically run `hg rebase --abort` to clear it, but that does an
`update` with `force=True` which can cause work to be lost.
This is just a quick bug fix. The right solution is to make an inmemory `mergestate` and not write it at all if rebasing in-memory.
Reviewed By: DurhamG
Differential Revision: D8517289
fbshipit-source-id: a62c99ccb2de1be102f9c23cd737794184c4fde8
Summary:
This fixes a subtle bug related to mergedrivers and IMM.
If your DAG looks like this:
```
dest (new mergedriver code)
|
| A (current commit)
|/
base (old mergedriver code)
```
And if you use IMM to rebase `A` onto `dest`, the wrong thing can happen because parts of `base`'s mergedriver are still loaded.
This only affected certain types of driver changes -- adding or removing parameters between files in the driver, or a driver change that also mutated the working copy (e.g. renaming a file checked by `preprocess()`). And, it only occurred if you had `A` (or some other change between `base` and `dest) checked out.
So, evict the old driver files, and all is well.
The right long-term fix is to probably implement our own Python loader for the mergedriver that reads all driver files from either the `source` or `dest` changectx not `.`. But, that's a bigger change.
Reviewed By: quark-zju
Differential Revision: D8464848
fbshipit-source-id: 8f03a4c99418aa26c3890989d19dd908b026c328
