Summary:
Now that all our repos are treemanifest, let's enable the extension by
default in tests. Once we're certain no one needs it in production we'll also
make it the default in core Mercurial.
This diff includes a minor fix in treemanifest to be aware of always-enabled
extensions. It won't matter until we actually add treemanifest to the list of
default enabled extensions, but I caught this while testing things.
Reviewed By: ikostia
Differential Revision: D15030253
fbshipit-source-id: d8361f915928b6ad90665e6ed330c1df5c8d8d86
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:
When you get an error, let's print the number of conflicts in each file. This will give the user some sense of how much work they have to do.
The code change is entirely in `filemerge.py`, and `tests/test-merge-conflict-count.t` adds a new test.
Reviewed By: quark-zju
Differential Revision: D9815243
fbshipit-source-id: 1b73a1db293902ac7242997a7d6ae09478344068
Summary:
Like D9323267, hg tests commonly reinvent common aliases to render the DAG, and they often differ very slightly. This makes adding a test require more boilerplate, and reading a test in a foreign new area slightly more overhead.
Let's standardize these to reduce the copypasta.
It's necessary to define this as a shell function instead of an hgrc alias to prevent tests that list aliases from printing it. Plus that enforces a nice separation of test/stdlib logic.
Bookmarks and branches are easy enough to add since they're empty if not used. A good number added `{phase}` -- I renamed this to `tglogp`.
Reviewed By: quark-zju
Differential Revision: D9347072
fbshipit-source-id: 6aac7de3e65d2295a7ebecd2ab30901709af3ff1
Summary: This will let us print more helpful/precise error messages.
Reviewed By: singhsrb
Differential Revision: D8699551
fbshipit-source-id: 060058eff925d94ffa8e6b4432c4e51bd93b2945
Summary: This config was needed when IMM restarts were long and painful, but now that they're not, this clunky and inaccurate hueristic can be removed, which simplifies the control flow a bit.
Reviewed By: singhsrb
Differential Revision: D8700868
fbshipit-source-id: 0aeac26e5c41f7f0260ee826f05a8f9047dbad5a
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:
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:
We bailifchanged() later on, but the abort does an `up -C originalwc` before that. Let's bailifchanged() immediately.
A better version: reset the transaction and clear the statefile, instead of calling `abort()`.
Reviewed By: quark-zju
Differential Revision: D7538017
fbshipit-source-id: 8c490b366e495bb269c4d8c75b6144c535c8d54f
Summary:
After testing locally, I couldn't conclusively prove if rebasing a single change with IMM was any faster or slower than on disk.
Using IMM on the working copy will definitely be better for rebasing stacks, and it's just nicer to not have the working copy thrash around as much. It also might be interesting to (possibly) let you work while the rebase is running, too.* So I've added the code that will let us enable this more widely (as a subset of IMM) to experiment.
*I've made it so that if you make any changes during the rebase (causing the last update to fail), we just print a nice message telling you to checkout the new rebased working copy commit, instead of failing/aborting. TBD whether this is something we want to encourage people to do, however. I've kept the existing up-front check for uncommited changes when rebasing the WCP with IMM for now.
Reviewed By: DurhamG
Differential Revision: D7051282
fbshipit-source-id: c04302539021f481c17e47c23d3f4d8b3ed59db6
Summary:
In an in-memory merge, if a commit only changed the flags of a file, and that file also never got written to during the merge, the IMM could fail and cause it to restart.
The reason is pretty simple: `setflags()` sets `cache[flags]` but not `cache[data]`, as it doesn't have any new data to store. In that case, calls to read the data should to fall-through to the underlying `p1` context.
Indeed, proper logic to do that already exists in `overlayworkingctx.data(path)` and `flags(path)`. The problem is that `tomemctx()` was reading from the cache directly, which is problematic and unhygenic. So let's just change it to call the proper functions, which also fixes the bug.
Reviewed By: DurhamG
Differential Revision: D7447640
fbshipit-source-id: 1625ef82ad2683c6a72059a0944fd5e336d3ec3a
Summary: This was just plain broken before. I added a test.
Reviewed By: DurhamG
Differential Revision: D6882388
fbshipit-source-id: 5450b50fa81d22ce0b6e9e4ed5aab1abc6755edc
Summary:
Since we have `debugbuilddag` as a builtin command, and `drawdag` is
pretty useful for writing clean test cases. Let's inline it. This would
simplify many tests since `drawdag=..." is no longer needed.
Reviewed By: DurhamG
Differential Revision: D6827925
fbshipit-source-id: b749f57fd5c55b2cb000dd2da2c2f9bc2386a519
Summary:
If `rebase.experimental.inmemory` was enabled, but you ended up merging on-disk (e.g. you rebased the working copy parent), and you got merge conflicts, and didn't immediately solve them, hg would discard any work you did and restart the rebase unnecessarily.
The bug here is basically that `rbsrt.inmemory` field can be set to False later, because we make further calculations once we define the `rebaseset`. In that case `InterventionRequired` will get raised if the user didn't solve conflicts, but we'll catch it, thinking something went wrong "in-memory", and abort/rerun the rebase. I was too hasty in adding the "catch all exceptions and retry" block.
I solved this two ways -- first, move the rbsrt definition here and explicitly check the state in the Exception catch. Second, add an explicit catch for InterventionRequired and explain why with a comment.
Further refactoring of the rebase code will help here, I think, so we can consolidate all of this logic.
Reviewed By: DurhamG
Differential Revision: D6817683
fbshipit-source-id: eb8baba86ec0deb59a1e0b1cf9ffb02f056ecd92
This is just a very simple start, but verifies some of the basic cases of an
in-memory rebase.
Differential Revision: https://phab.mercurial-scm.org/D1652
