The ':fail' tool now knows to write out the changed side for change/delete
conflicts.
This has no impact right now but will make things better when we move
change/delete conflicts in here.
We do this because we don't want to modify the dirstate for failures, and don't
just want to leave the file missing from disk. Plus it's more useful for the
user if the changed side is written out -- it is easier to delete a file than
to get it back via hg revert.
Once we move change/delete conflicts into the resolve phase, a 'dc' file might
first be resolved by picking the other side, then later be resolved by picking
the local side. For this transition we want to make sure that the file goes
back to not being in the dirstate.
This has no impact on conflicts during the initial merge.
At the moment this is a no-op (the only actions defined are 'r', 'a' and 'g'),
but soon we're going to add other sorts of actions to the dictionary returned
from mergestate.actions().
This should have been done as part of or as an immediate follow-up to
01b01d59e33f, but presumably this feature of extensions.py was
forgotten at that time.
The next patch will remove the progress extension completely, so we have
to pick another extension. The schemes is picked arbitrary.
This test was introduced at 57703c45ed60.
It was previously not at all obvious what this was for.
We also change it to a set to avoid iterating over an admittedly
small list repeatedly at startup time.
In many cases, we don't need to cast to a str because the object will
be cast when it is eventually written.
As part of testing this, I added some code to raise exceptions when a
non-str was passed in and wasn't able to trigger it. i.e. we're already
passing str into this function everywhere, so the casting isn't
necessary.
Previously, we stored 2-tuples of text and label in a list and then
evaluated the labels when the buffer was popped. After this patch,
we evaluate the labels at write time and do a simple join when the
buffer is popped.
This patch appears to have no impact on performance, despite creating
fewer 2-tuples and having fewer strings hanging around in memory.
This doesn't yet change behavior because labeling is still performed
at popbuffer time.
Surprisingly, this is the only in-tree consumer that passes
labeled=True.
As part of profiling `hg log` performance, I noticed a lot of time
is spent in buffered writes to ui instances. This patch starts a series
that refactors buffered writes with the eventual intent to improve
performance.
Currently, labels are expanded when buffers are popped. This means
we have to preserve the original text and the label until we render
the final output. This is avoidable overhead and adds complexity
since we're retaining state.
This patch adds functionality to ui.pushbuffer() to declare whether
label expansion should be active for the buffer. Labels are still
evaluated during buffer pop. This will change in a subsequent
patch.
Since we'll need to access the "expand labels" flag on future write()
operations, we prematurely optimize how the current value is stored
to optimize for rapid retrieval.
Since we have pushed back the performance issue related to general delta behind
another configuration (Still off by default), we can safely create new
repository with general delta support. As client are compatible with it since
Mercurial 1.9 (4.5 years ago) I do no expect any significant compatibility
issues.
If detailed conflict markers are enabled and the closing quote gets truncated,
editors will often screw syntax highlighting up from that point because they'll
see an opening quote and think it's the beginning of a string.
In tests, the hashes change because the commit messages of the shelved bundles
also change.
These are meant for use by custom merge drivers that might want to modify the
dirstate. Dirstate internal consistency rules require that all removes happen
before any adds -- this means that custom merge drivers shouldn't be modifying
the dirstate directly.
Used a class as a namespace, and then wired up a classmethod to return
all known constraints. I'm mostly happy with this, even though it's
kind of weird for hg.
This is a first (very simple) version of the histedit base action.
It works well in common usecases like rebasing the whole stack and
spliting the stack.
I don't see any obvious edge cases - but probably there is more than one.
That's why I want to keep it behind experimental.histeditng config knob
for now. I think on knob for all new histedit behaviors is better because
we will test all of them together and testers will need to turn it on only
once to get all new nice things.
For the future 'base' action in histedit we need a verification
constraint which will not allow using this action with changes
that are currently edited.
Before we can add a 'base' action to histedit need to change verification
so that action can specify which steps of verification should run for it.
Also it's everything we need for the exec and stop actions implementation.
I thought about baking verification into each histedit action (so each
of them is responsible for verifying its constraints) but it felt wrong
because:
- every action would need to know its context (eg. the list of all other
actions)
- a lot of duplicated work will be added - each action will iterate through
all others
- the steps of the verification would need to be extracted and named anyway
in order to be reused
The verifyrules function grows too big now. I plan to refator it in one of
the next series.
We're going to use this to extend the action lists in merge.applyupdates.
The somewhat funky return value is to make passing this dict directly into
recordactions easier. We're going to exploit that in an upcoming patch.
This eliminates a whole bunch of duplicate code and allows us to update the
removed count for change/delete conflicts where the delete action was chosen.
This will not only allow us to remove a bunch of duplicate code in applyupdates
in an upcoming patch, it will also allow the resolve interface to be a lot
simpler: it doesn't need to return the dirstate action to applyupdates.
Many revset consumers construct changectx instances for each returned
result. Add support for benchmarking this to our revset benchmark
script.
In the future, we might want to have some kind of special syntax in
the parsed revset files to engage this mode automatically. This would
enable us to load changectxs for revsets that do that in the code and
would more accurately benchmark what's actually happening. For now,
running all revsets with or without changectxs is sufficient.
Previously, perfrevset called repo.revs(), which only returns integer
revisions. Many revset consumers call repo.set(), which returns
changectx instances. Or they obtain a context manually later.
Since obtaining changectx instances when evaluating revsets is common,
this patch adds support for benchmarking this use case.
While we added an if conditional for every benchmark loop, it
doesn't appear to matter since revset evaluation dwarfs the cost
of a single if.
