As the author of several 3rd party extensions, I frequently see bug
reports from users attempting to run my extension with an old version
of Mercurial that I no longer support in my extension. Oftentimes, the
extension will import just fine. But as soon as we run extsetup(),
reposetup(), or get into the guts of a wrapped function, we encounter
an exception and abort. Today, Mercurial will print a message about
extensions that don't have a "testedwith" declaring explicit
compatibility with the current version.
The existing mechanism is a good start. But it isn't as robust as I
would like. Specifically, Mercurial assumes compatibility by default.
This means extension authors must perform compatibility checking in
their extsetup() or we wait and see if we encounter an abort at
runtime. And, compatibility checking can involve a lot of code and
lots of error checking. It's a lot of effort for extension authors.
Oftentimes, extension authors know which versions of Mercurial there
extension works on and more importantly where it is broken.
This patch introduces a magic "minimumhgversion" attribute in
extensions. When found, the extension loading mechanism will compare
the declared version against the current Mercurial version. If the
extension explicitly states we require a newer Mercurial version, a
warning is printed and the extension isn't loaded beyond importing
the Python module. This causes a graceful failure while alerting
the user of the compatibility issue.
I would be receptive to the idea of making the failure more fatal.
However, care would need to be taken to not criple every hg command.
e.g. the user may use `hg config` to fix the hgrc and if we aborted
trying to run that, the user would effectively be locked out of `hg`!
A potential future improvement to this functionality would be to catch
ImportError for the extension/module and parse the source code for
"minimumhgversion = 'XXX'" and do similar checking. This way we could
give more information about why the extension failed to load.
The next patch will merge the cmdutil.service() calls of both commandserver
and hgweb. Before doing it, this patch wipes out the code specific to hgweb
from commands.serve().
We have finally laid all the groundwork to make this happen.
The only change/delete conflicts that haven't been moved are .hgsubstate
conflicts. Those are trickier to deal with and well outside the scope of this
series.
We add comprehensive testing not just for the initial selections but also for
re-resolves and all possible dirstate transitions caused by merge tools. That
testing managed to shake out several bugs in the way we were handling dirstate
transitions.
The other test changes are because we now treat change/delete conflicts as
proper merges, and increment the 'merged' counter rather than the 'updated'
counter. I believe this is the right approach here.
For third-party extensions, if they're interacting with filemerge code they
might have to deal with an absentfilectx rather than a regular filectx.
Still to come:
- add a 'leave unresolved' option to merges
- change the default for non-interactive change/delete conflicts to be 'leave
unresolved'
- add debug output to go alongside debug outputs for binary and symlink file
merges
This is so much easier to read than a long string of zeroes, and we're going to
have a lot more of these nodes once change/delete conflicts are part of the
merge state.
This is somewhat different from the currently existing 'a' action, for the
following case:
- dirty working copy, with file 'fa' added and 'fm' modified
- hg merge --force with a rev that neither has 'fa' nor 'fm'
- for the change/delete conflicts we pick 'changed' for both 'fa' and 'fm'.
In this case 'branchmerge' is true, but we need to distinguish between 'fa',
which should ultimately be marked added, and 'fm', which should be marked
modified.
Our current strategy is to just not touch the dirstate at all. That works for
now, but won't work once we move change/delete conflicts to the resolve phase.
In that case we may perform repeated re-resolves, some of which might mark the
file removed or remove the file from the dirstate. We'll need to re-add the
file to the dirstate, and we need to be able to figure out whether we mark the
file added or modified. That is what the new 'am' action lets us do.
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.
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.
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.
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.
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.
ui.write() has 2 modes: buffered and unbuffered. In buffered mode, we
capture output before writing it. This is how changeset printing works,
for example.
Previously, we were potentially clearing the progress bar for every
call to ui.write(). In buffered mode, this clearing was useless because
the clearing function would be called again before actually writing
the buffered data.
This patch stops the useless calling of _progclear() unless we are
actually writing data. During changeset printing with the default
template, this removes ~6 function calls per changeset, making
changeset printing slightly faster.
before: 23.76s
after: 23.35s
delta: -0.41s (98.3% of original)
We were computing the quotient and remainder of a division operation
separately. The built-in divmod() function allows us to do this with
a single function call. Do that.
Before, we passed the node then subsequently performed a lookup on
repo.changelog. We already has the context available, so just pass it
in.
This does result in a small performance win. But I doubt it will show
up anywhere because diff[stat] calculation will dwarf the time spent
to create a changectx. Still, we should be creating fewer changectx
out of principle.
Resolving parents requires reading from the changelog, which is a few
attributes and function calls away. Parents lookup occurs surprisingly
often. Micro optimizing the code to avoid redundant lookups of parents
appears to make `hg log` on my Firefox repo a little faster:
before: 24.91s
after: 23.76s
delta: -1.15s (95.4% of original)
This patch avoids some extra attribute lookups and list mutations.
This micro-optimization seems to result in a minor speedup for `hg log`
on my Firefox repo:
before: 25.35s
after: 24.91s
delta: -0.44s (98% of original)
Not the biggest gain. But every little bit helps.
PyPy's _lsprof module doesn't export a "profiler_entry" symbol. This
patch treats the symbol as optional and falls back to verifying the
attribute is present on the first entry in the collected data as
part of validation.
There is a chance not every entry will contain the requested sort
attribute. But, this patch does unbust lsprof on PyPy for the hg
commands I've tested, so I assume it is sufficient. It's certainly
better than the ImportError we encountered before.
As part of the import refactor, I snuck in the addition of
absolute_import.
